¿Terracotta hace que JMS sea una capa innecesaria?

Question

Actualmente estamos escribiendo una aplicación para la que TI ya ha comprado hardware. Su enfoque era comprar un gran hardware sobre el que implementaríamos. Para agregar más procesamiento, planean agregar servidores adicionales con software idéntico. Para acomodar este diseño, estamos usando Terracotta para proporcionar la capacidad de ejecutar varias JVM como si fuera una gran. Independientemente de si este es un camino inteligente (que todavía no estoy convencido), esta es la situación con la que estoy lidiando.

De todos modos, tenemos una parte de la aplicación que utiliza una cola de tipo productor/consumidor estándar. Con Terracotta, podemos crear una única cola que funcione con varias JVM. Esto es bastante astuto y funciona bien.

Pero ahora, estamos encontrando oportunidades adicionales para ejecutar procesos asincrónicos. Para que toda nuestra lógica de colas sea más consistente, estamos considerando usar JMS para abstraer la lógica común. Dado que no vamos a utilizar JMS como una cola remota (al menos en el futuro previsible), me pregunto si JMS solo está agregando complejidad innecesaria.

¿Alguna sugerencia o idea? ¿Deberíamos continuar creando colas como estructuras concurrentes, o tratarlas como objetos separados y potencialmente remotos?

Answer 1

Una cola de mensajes es esencialmente solo la estructura de datos Queue que tiene algunas opciones sofisticadas. Si su proyecto es como la mayoría de los otros proyectos, no es utilizando ninguna de las funciones de JMS que hacen que JMS sea diferente de cualquier implementación anterior de Queue, especialmente dado que Terracotta maneja la persistencia y la distribución.

Así que JMS probablemente solo esté agregando complejidad a su aplicación, que es algo en lo que JMS es bastante bueno. Como todos los controladores innecesarios de complejidad, deshágase de eso. Si alguna vez decide usar JMS por una o más razones, hágalo en ese momento.

Answer 2

Un colega mío ha estado usando Mule, lo que le permite definir colas que pueden ser colas JVM internas o internas.

Estoy de acuerdo con krosenwald: no está claro lo que JMS sería añadir en su caso, a menos que haya un plan general a cualquiera de alejarse de terracota (o al menos tener la opción).

Answer 3

No he usado Terracotta pero estamos usando un producto de caché distribuido muy similar. Nuestra arquitectura también suena similar a lo que tienes. Tanto los productores como los consumidores se sientan en la misma memoria caché y comparten datos utilizando el subsistema de almacenamiento en caché.

Si bien estoy de acuerdo con el principio de que agregar JMS ahora podría ser una complejidad innecesaria para usted, hemos encontrado que, aunque resbaladiza, la memoria caché distribuida no es la mejor implementación de un mecanismo de mensajería. Aunque se pueden crear las mismas características, algunos detalles pequeños causan problemas (como el equilibrio de carga para los consumidores, que pueden requerir una sincronización adicional con un caché distribuido, pero funcionan naturalmente con JMS).

Si cree que sus casos de uso futuros requiere más semántica pub-sub con persistencia, etc., es posible que desee comenzar a pensar en JMS. Además, considere la separación de las preocupaciones. Está utilizando Terracotta para distribuir datos (que es lo que está diseñado para hacer). ¿También lo usará para distribuir instrucciones de control (que se hace mejor con la semántica de mensajes)?