Est-ce que Terracotta fait du JMS une couche inutile?

Question

Nous sommes en train d'écrire une application pour laquelle IT a déjà acheté du matériel. Leur approche consistait à acheter du gros matériel sur lequel nous allions nous déployer. Afin d'ajouter plus de traitement, ils prévoient d'ajouter des serveurs supplémentaires avec des logiciels identiques. Afin d'accommoder cette conception, nous utilisons Terracotta pour fournir la possibilité d'exécuter plusieurs JVM comme s'il s'agissait d'une grande machine. Peu importe si c'est une sage façon d'aller (ce dont je ne suis toujours pas convaincu), c'est la situation à laquelle je fais face.

De toute façon, nous avons une partie de l'application qui utilise une file d'attente de type producteur/consommateur standard. Avec Terracotta, nous sommes en mesure de créer une seule file d'attente qui fonctionne avec plusieurs JVM. C'est assez lisse et ça marche bien.

Mais maintenant, nous trouvons des opportunités supplémentaires pour exécuter des processus asynchrones. Pour rendre la logique de mise en file d'attente plus cohérente, nous envisageons d'utiliser JMS pour extraire la logique commune. Puisque nous n'allons pas utiliser JMS comme une file d'attente distante (au moins dans un avenir prévisible), je me demande si JMS ne fait qu'ajouter une complexité inutile.

Des suggestions ou des idées? Devrions-nous simplement continuer à créer des files d'attente en tant que structures concurrentes, ou les traiter comme des objets distincts et potentiellement distants?

Answer 1

Une file d'attente de messages est essentiellement une structure de données de file d'attente qui a quelques options de fantaisie. Si votre projet est comme la plupart des autres projets, vous n'êtes pas en utilisant aucune des fonctionnalités JMS qui rendent JMS différent de toute ancienne implémentation Queue, d'autant plus que Terracotta gère la persistance et la distribution. Par conséquent, JMS ajoute probablement de la complexité à votre application, ce à quoi JMS est très bon. Comme tous les conducteurs inutiles de complexité, éliminez-le. Si jamais vous décidez d'utiliser JMS pour une ou plusieurs raisons, faites-le alors.

Answer 2

Un de mes collègues utilise Mule, ce qui vous permet de définir des files d'attente qui peuvent être des files d'attente intra ou inter-JVM. Je suis d'accord avec krosenwald: on ne sait pas ce que JMS ajouterait dans votre cas, à moins qu'il n'y ait un plan général pour s'éloigner de Terracotta (ou au moins avoir l'option de).

Answer 3

Je n'ai pas utilisé Terracotta mais nous utilisons un produit de cache distribué très similaire à celui-ci. Notre architecture ressemble aussi à ce que vous avez. Avec les producteurs et les consommateurs assis sur le même cache et le partage de données en utilisant le sous-système de mise en cache. Bien que je sois d'accord sur le principe que l'ajout de JMS peut maintenant être une complexité inutile pour vous, nous avons constaté que, bien que lisse, le cache distribué n'est pas la meilleure implémentation d'un mécanisme de messagerie. Bien que les mêmes données sémantiques puissent être créées, certains petits détails provoquent des problèmes (tels que l'équilibrage de charge pour les consommateurs, qui peut nécessiter une synchronisation supplémentaire avec un cache distribué, mais fonctionne naturellement avec JMS).

Si vous pensez que vos futurs cas d'utilisation exiger plus de sémantique de pub-sub avec la persistance etc., vous pourriez vouloir commencer à penser à JMS. En outre, envisager la séparation des préoccupations. Vous utilisez Terracotta pour distribuer des données (ce pour quoi il est conçu). L'utiliserez-vous également pour distribuer des instructions de contrôle (ce qui est mieux fait avec la sémantique de messaing)?