REST service en attente sur une réponse des processus asynchrones

ont un service REST développé avec Spring BootREST service en attente sur une réponse des processus asynchrones

L'API utilise actuellement JMS pour publier un sujet & le sujet a plusieurs abonnés.

Maintenant, nous avons un processus « X », qui consolide la réponse de ces sujets et pousse la réponse à une file d'attente.

Maintenant, je voudrais avoir l'API (service REST) attendre cette file d'attente (publié par « X ») - pour le traitement synchrone.

Est-ce que JMSReplyTo prendrait en charge un tel cas? http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html

Edit:

Pour simplifier

Dans l'exemple (fourni dans le lien ci-dessus) - serveur interroge la file d'attente à & attend sur c'est la réponse.

Nos sondages services REST à la file d'attente & doit attendre sur une autre file d'attente.

En d'autres termes - Comment un service Web attente & lecture de la file d'attente - à laquelle il n'a pas encore posté de

Source

2016-02-08 Narendra N

peut être en réponse que vous envoyez l'identificateur de votre message. et à la fin du magasin de traitement JMS quelque part le résultat du traitement JMS. et dans votre client introduire un sondage simple sur l'obtention des résultats en fonction de cet identificateur.Ou créez simplement le WebSocket (mais celui-ci n'est pas un service REST) –

Oui, pour l'instant - je retourne un UUID et demande aux clients de lire en fonction de l'UUID –

Ce que nous avons fait pour résoudre le problème est - Je ne sais pas, c'est la bonne façon de faire

Null Sur le défaut JMSreplyTo
Ajout notre tête personnalisé "ReplyTo"

Même si nous passons à JMSReplyTo une autre file d'attente - nous avons observé que la réponse revient à l'appelant (API REST) juste après le traitement du message par la file d'attente. Comme nous supprimons le JMSReplyTo - il ne retournait pas la réponse. Ensuite, comment la réponse revient à l'API REST - la raison pour laquelle nous avons créé l'en-tête personnalisé - ReplyTo

Chaque file d'attente est maintenue lors du passage de l'en-tête ReplyTo à toutes les autres files d'attente, où le message est transmis pour traitement ultérieur .

Si avec l'une des files d'attente, il n'y a pas d'autre traitement (qui dépend de certaines conditions sur les données, client et ...) - Fait la queue de retour à ReplyTo - qui était la file d'attente JMS originale, API REST attendait.

Cela a fonctionné de manière cohérente. Cependant, avec quelques problèmes de performance - en considérant, le message est passé à plusieurs files d'attente.

Cependant, compte tenu de la tâche principale de cette API est pour vous assurer que les données sont transmises à tous les systèmes (point d'intégration) - il fait son travail.

Nous reviendrons à nouveau pour voir comment nous pouvons changer la conception pour un meilleur débit.

Source

2016-05-10 09:18:37

REST service en attente sur une réponse des processus asynchrones

Répondre

Questions connexes