Quelles sont les différences en utilisant les acteurs Scala au lieu de JMS ?
Par exemple, du point de vue des performances et de l'évolutivité, qu'apporte le modèle Scala Actor par rapport à JMS ? Dans quels cas est-il plus judicieux d'utiliser les acteurs plutôt que JMS, c'est-à-dire quels sont les problèmes que les acteurs résolvent et que JMS ne peut pas couvrir ?
Les acteurs JMS et Scala partagent une similitude théorique, mais ne pensez pas qu'ils résolvent nécessairement les mêmes problèmes sur le plan architectural. Les acteurs sont censés être une alternative légère à la concurrence en mémoire partagée où les courses et les blocages sont généralement plus difficiles à créer accidentellement. JMS est une API sophistiquée destinée à couvrir la messagerie directe, la publication/abonnement, les transactions, l'intégration EJB, etc.
L'équivalent JMS le plus proche d'un acteur serait un bean piloté par message qui est soutenu par une file d'attente non persistante, non transactionnelle et non sub/sub. J'appellerai cela un "simple JMS bean".
Maintenant, à vos questions.
Il est difficile de parler de performances car JMS est une spécification plutôt qu'une implémentation. Néanmoins, en utilisant un simple haricot JMS, je m'attends à ce que les performances soient à peu près similaires, avec peut-être un léger avantage pour l'acteur en termes de temps et de mémoire. Lorsque vous ajoutez des fonctionnalités à JMS, telles que pub/sub, transactions, etc., les performances se dégradent naturellement encore plus, mais vous essayez alors de comparer des pommes et des oranges.
En ce qui concerne l'évolutivité, les beans JMS simples devraient évoluer à peu près de la même manière que les acteurs. L'ajout de transactions dans le mélange JMS va naturellement nuire à l'évolutivité dans une mesure qui dépend de la portée des transactions.
La question plus large est de savoir ce que les acteurs font que JMS ne peut pas faire. Eh bien, sans pub sub ou transactions intégrées, il semblerait que les acteurs soustraient du JMS - et dans l'ensemble c'est vrai. Mais voici la chose : les acteurs requièrent si peu de code que je peux les utiliser avec plaisir pour une concurrence très fine. Dans un code Java ordinaire, je pourrais dire : "Je n'ai pas envie de m'embêter avec JMS et ses dépendances ou le code qu'il requiert, etc., alors je vais juste créer un thread, utiliser un verrou et partager une structure de données". Avec les acteurs Scala, je suis beaucoup plus susceptible de dire "Je vais juste créer un acteur et passer à autre chose".
Il y a aussi une différence philosophique dans la conception. Les acteurs ont un concept simple et intégré de hiérarchies de superviseurs. Les acteurs sont généralement utilisés dans une conception de type "laissez-le se planter". Si un acteur meurt pour une raison quelconque, un autre acteur est chargé de décider ce qu'il faut faire, par exemple redémarrer cet acteur, tuer un groupe d'acteurs et les redémarrer tous, ou tuer un groupe d'acteurs et lui-même pour qu'un autre acteur puisse s'occuper du problème. Ce genre de choses peut être ajouté à JMS, mais il n'est pas au cœur de l'API et doit être géré en externe d'une manière ou d'une autre.
À propos, pour une bibliothèque d'acteurs Scala qui se rapproche des domaines couverts par JMS, voir Akka . Akka apporte également une approche déclarative à de nombreuses stratégies courantes de hiérarchie des acteurs.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
