JMS entre les applications d'entreprise

Question

Nous avons un projet dans lequel nous voulons lier deux systèmes d'entreprise à l'aide de JMS. En résumé, le système 1 envoie un message à la file d'attente. Systems2 récupère ce message, effectue une charge complète de traitement en arrière-plan pendant environ 30 minutes, puis envoie un message à la file d'attente pour que System1 prenne le relais. Pouvons-nous nous en sortir avec 1 file d'attente ou avons-nous besoin de 2? Si nous avons 2 files d'attente alors, System1 écrit dans queue1, System2 décroche. Lorsque system2 est prêt, il écrit dans queue2 et System1 le récupère.

Quelle approche serait la meilleure? Si quelqu'un connaît les limites de ces approches, ou de meilleures solutions, alors s'il vous plaît faire part

Merci Damien

Answer 1

Vous pouvez utiliser des sélecteurs sur une file d'attente, mais je vous conseille de garder les choses simples et en utilisant 2 files d'attente comme vous l'avez décrit. Je préfère les types de messages de domaine dans des files d'attente distinctes et je pense que vous trouverez cela le plus facile à gérer aussi.

Une file d'attente est en grande partie juste un nom logique pour un ensemble de messages et peu ou pas de surcharge supplémentaire que tous les messages d'une seule file d'attente.

Answer 2

S'il s'agit d'une interface peer-to-peer dédiée et qu'aucune de ces applications ne fonctionne comme un serveur, vous pouvez vous en sortir avec une seule file d'attente. Cependant, ce modèle ne prend pas en charge le modèle client-serveur. D'autre part, le modèle client-serveur prend en charge une interface peer-to-peer ainsi qu'une interface client-serveur et il n'est pas plus difficile à implémenter, alors pourquoi ne pas l'utiliser?

Spécifiquement, un serveur écoute dans une file d'attente bien connue. Toute application souhaitant piloter ce service envoie un message à la file d'attente bien connue. Le message contient l'adresse d'une destination de réponse et le serveur envoie la réponse à cette destination. De cette façon, une application serveur peut traiter des demandes provenant de nombreux clients relativement anonymes (ou authentifiés si désiré) n'importe où sur le réseau. Cette approche prend également en charge la file d'attente client et serveur ne se trouvant pas sur le même moteur de message. Il supporte l'accès aux files d'attente en mode FIFO qui devrait être plus performant. Il gère le cas de messagerie asynch classique de producteur rapide, consommateur lent mieux qu'une seule file d'attente. Il prend en charge les destinations de réponse dynamiques. Cela permet de relocaliser les applications indépendamment les unes des autres. Et si ce que vous avez est vraiment un peer-to-peer sans éléments du pattern client-serveur, alors cette architecture le supporte aussi.