Quelles décisions de conception favoriseraient les acteurs de Scala au lieu de JMS?

Quelles sont les différences en utilisant Scala Actors au lieu de JMS?

Par exemple, du sharepoint vue des performances et de l’évolutivité, que ajoute le modèle Scala Actor par rapport à JMS? Dans quels cas est-il plus judicieux d’utiliser des acteurs plutôt que JMS, c.-à-d. Quels problèmes les acteurs traitent-ils que JMS ne peut pas résoudre?

Les acteurs JMS et Scala partagent une similitude théorique mais ne les considèrent pas nécessairement comme résolvant les mêmes problèmes sur le plan architectural. Les acteurs se veulent 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 géré par un message, soutenu par une queue non-pub / sub non persistante et non transactionnelle. Je vais appeler ça un “simple bean JMS”.

Maintenant, à vos questions.

Les performances sont difficiles à décrire, car JMS est une spécification plutôt qu’une implémentation. Néanmoins, en utilisant un bean JMS simple, je m’attendrais à ce que les performances soient à peu près similaires, avec peut-être un petit 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 vont naturellement se dégrader encore plus, mais vous essayez de comparer des pommes à des oranges.

En ce qui concerne l’évolutivité, les beans JMS simples devraient évoluer de la même manière que les acteurs. L’ajout de transactions au mixage JMS nuira naturellement à l’évolutivité en fonction de la scope des transactions.

La question plus large de ce que font les acteurs que JMS ne peut pas. Eh bien, sans sous-pub ou transactions intégrés, il semblerait que les acteurs soustraient à JMS – et en gros c’est vrai. Mais voici la chose: les acteurs ont besoin de si peu de code que je peux les utiliser avec bonheur pour une concurrence très fine. Dans le code Java ordinaire, je pourrais dire “je n’ai pas envie de visser avec JMS et ses dépendances ou le code requirejs, alors je vais juste créer un thread, utiliser un verrou et partager une structure de données.” Avec les acteurs de la Scala, je suis beaucoup plus enclin à dire “Je vais juste créer un acteur et aller de l’avant”.

Il y a aussi une différence de conception philosophique. Les acteurs ont un concept simple et intégré de hiérarchies de superviseurs. Les acteurs sont généralement utilisés dans un design “let it crash”. Si un acteur meurt pour une raison quelconque, un autre acteur est responsable de décider quoi faire, par exemple de redémarrer cet acteur, de tuer un groupe d’acteurs et de les redémarrer, ou de tuer un certain nombre d’acteurs. traiter le problème. Ce genre de chose peut être ajouté à JMS, mais ce n’est pas essentiel à l’API et doit être géré de manière externe.

En passant, pour une bibliothèque d’acteurs Scala qui se déplace davantage dans les domaines couverts par JMS, consultez Akka . Akka apporte également une approche déclarative à de nombreuses stratégies courantes de hiérarchie des acteurs.