¿Cuáles son las diferencias al usar Scala Actors en lugar de JMS?
Por ejemplo, desde una perspectiva de rendimiento y escalabilidad, ¿qué aporta el modelo Scala Actor en comparación con JMS? ¿En qué casos tiene más sentido usar Actors en lugar de JMS, es decir, qué problemas resuelve Actors que JMS no puede cubrir?
Respuestas:
Los actores de JMS y Scala comparten una similitud teórica, pero no piensan que necesariamente resuelvan los mismos problemas arquitectónicamente. Los actores están destinados a ser una alternativa liviana a la concurrencia de memoria compartida donde las carreras y los puntos muertos son generalmente más difíciles de crear accidentalmente. JMS es una API sofisticada que está destinada a abarcar mensajería directa, publicación / suscripción, transacciones, integración de EJB, etc.
El equivalente JMS más cercano a un actor sería un bean controlado por mensajes que está respaldado por una cola de publicación / sub no persistente, no transaccional. Llamaré a eso un "bean JMS simple".
Ahora, a tus preguntas.
Es difícil hablar de rendimiento, ya que JMS es una especificación más que una implementación. No obstante, al usar un bean JMS simple, esperaría que el rendimiento sea aproximadamente similar con quizás un poco de ventaja para el actor en tiempo y memoria. A medida que agregue capacidades a JMS, como pub / sub, transacciones, etc., el rendimiento se degradará aún más, pero luego estará tratando de comparar manzanas con naranjas.
En cuanto a la escalabilidad, los beans JMS simples deberían escalar casi exactamente de la misma manera que los actores. Agregar transacciones a la combinación de JMS afectará naturalmente la escalabilidad en una cantidad que depende del alcance de las transacciones.
La cuestión más amplia de qué hacen los actores que JMS no puede. Bueno, sin transacciones o sub-pub integrados, parecería que los actores restan de JMS, y en general eso es cierto. Pero aquí está la cuestión: los actores requieren tan poco código que puedo usarlos felizmente para una concurrencia muy fina. En el código Java ordinario podría decir "No tengo ganas de jugar con JMS y sus dependencias o el código que requiere, etc., así que solo generaré un hilo, usaré un bloqueo y compartiré una estructura de datos". Con los actores de Scala, es mucho más probable que diga "simplemente azotaré a un actor y seguiré adelante".
También hay una diferencia filosófica en el diseño. Los actores tienen un concepto simple e integrado de jerarquías de supervisores. Los actores se utilizan generalmente en un diseño de "dejar que se estrelle". Si un actor muere por alguna razón, otro actor es responsable de decidir qué hacer al respecto, como reiniciar ese actor, matar a un grupo de actores y reiniciarlos a todos, o matar a un grupo de actores y a sí mismo para que otro actor pueda hacerlo. lidiar con el problema. Ese tipo de cosas se pueden agregar a JMS, pero no es fundamental para la API y debe administrarse externamente de alguna manera.
Por cierto, para una biblioteca de actores de Scala que se mueva más hacia los reinos que cubre JMS, vea Akka . Akka también aporta un enfoque declarativo a muchas estrategias comunes de jerarquía de actores.