¿Por qué debería usar JMS y no RMI + Queue?

Question

Por el momento estoy usando RMI o hessian library para comunicarme entre mi servidor y mis clientes (a través de LinkedBlockingQueue). Ahora leo sobre JMS que también podría usarse en esta área. ¿Es esto correcto? En caso afirmativo, ¿le importaría darme una lista simple de ventajas/desventajas, porque parece ser un área bastante complicada y de "empresa completa".

¿Cuáles son los beneficios? ¿Y el rendimiento comparado con RMI + Queue? ¿Podría JMS vencer a RMI + Queue?

PD: Sé que hay similar questions, pero me gustaría tener JMS en comparación con RMI + Queue.

Answer 1

Una comparación simplificada sería (no son específicas de JMS, más como la comparación con MQ en general) ...

1. reintento automático de
   Si usted es un cliente haciendo un RMI a un servidor y para alguna razón por la cual RMI falla, debes intentarlo tú mismo. Si usara JMS y usted es el cliente, solo enviaría el mensaje JMS. Cuando el servidor no puede ser alcanzado, su mensaje será almacenado y luego entregado cuando el servidor esté nuevamente activo.

2. cola persistente
   Puesto que usted está usando un LinkedBlockingQueue, puede tener una cola limitada o una cola sin límites en memoria. El primero comenzará a atrapar hilos una vez que la cola esté llena y eventualmente fallará cuando haya mucha carga. Lo último eventualmente arrojaría OutOfMemoryError en su lugar. Sin embargo, si usa JMS, puede comenzar automáticamente a "persistir" mensajes a "almacenamiento persistente". Normalmente, el "almacenamiento persistente" es DB, que generalmente tiene mucha más capacidad que la cola en memoria. Por supuesto, el contenido de la cola en memoria se pierde cuando el servidor deja de funcionar, etc., mientras que en JMS puede elegir mensajes permanentes/mensajes persistentes que sobreviven a dicho evento. Esto también le permite tener la agrupación, que también es muy importante para los programas de la empresa ...

3. Abstracción
   Usted va a utilizar una API estándar (bueno, usted tiene los protocolos en RMI también, pero si lo que quiere está pasando mensajes, MQ proporciona mucha más abstracción de alto nivel que RMI + cola en memoria). Lo que significa que puedes usar futuras implementaciones de JMS.Tal vez algo que no necesita una base de datos para proporcionar durabilidad y persistencia, más escalable que la implementación actual, etc. O tal vez puede enviar el mismo mensaje a un servicio completamente diferente, debido a la estabilización. Básicamente, la abstracción más alta podría darle flexibilidad, que la cola en memoria RMI + no lo hace.

Hace algún tiempo, trabajé con una gran compañía que quería utilizar su marco interno para integrar nuestras cosas. En ese momento no estábamos usando un MQ. Les pedimos que usen nuestro propio protocolo asincrónico basado en RMI. Confíe en mí, lamentamos mucho esa decisión ...

Answer 2

¿Qué está utilizando para la parte "Queue" de su solución? ¿Tu propio código?

JMS es solo una API sobre el sistema de cola de algún proveedor, pero que incorpora los aspectos remotos. Entonces, desde la perspectiva del cliente, simplemente coloca un mensaje en una cola (o tema si está haciendo pub sub), y se olvida de ello. La infraestructura lo entrega al oyente (s).

Veo que gran parte del poder de JMS proviene de la calidad de la implementación de la infraestructura de cola en lugar de la API en sí misma, eso es bastante simple.

Simple RMI no escala bien o se ocupa de problemas de confiabilidad, un buen sistema de colas puede ser tanto escalable como resistente.

Creo que es justo decir que JMS y el resto de Java EE están destinados a permitir que su aplicación sea de calidad empresarial. Inicialmente, creo que Java EE general era complejo, aunque pensé que JMS era uno de los rincones más simples. Hoy, no estoy seguro de que escribir RMI + tu propia cola sea más fácil que simplemente usar JMS.

Posiblemente una diferencia significativa es que el uso de JMS asume que tiene alguna infraestructura, como un Servidor de aplicaciones en su lugar.

Answer 3

JMS es transaccional, se puede coordinar con transacciones de bases de datos.
JMS Desacopla a los productores y consumidores, lo que significa que no necesitan ejecutarse al mismo tiempo.
JMS Es la entrega garantizada, lo que significa que los mensajes están garantizados para llegar allí, en caso de una falla (dependiendo del tipo de falla puede requerir la agrupación).
JMS Puede hacer sincrones, asincrónicos punto a punto, así como Publicar/Suscribir.
La mayoría de las implementaciones JMS utilizan un sistema de colas que puede funcionar con otros lenguajes, sistemas operativos.

Answer 4

Las otras respuestas cubren muchos aspectos de JMS, pero creo que es muy importante que necesite más énfasis, es decir, el hecho de que JMS admite consumidores concurrentes múltiples de forma transaccional. Esta es para mí la característica asesina .

1. Se puede construir fácilmente un sistema con un solo consumidor y productor que no es tramitado.
2. También puede hacer que (más o menos) transaccional con un poco más de trabajo.
3. Del mismo modo, puede agregar soporte para productor múltiple y un único consumidor de manera relativamente fácil, por ejemplo, si usa una base de datos transaccional para almacenar el mensaje.
4. Pero se vuelve muy difícil tener consumidor simultáneo múltiple y tener el consumo de mensajes sea transaccional. Esto básicamente requiere un esquema de bloqueo no trivial, e incluso con el uso de una base de datos transaccional la tarea no es fácil.

Cuando hablamos de JMS escalabilidad, que sin embargo se habla de esto: la capacidad de la aplicación. servidor para agregar/eliminar consumidor/productor para administrar la carga.

Otras ventajas de JMS son la calidad del servicio y la gestión, p. intento de reenvío, cola de mensajes muertos, monitoreo, etc.

Si realmente no necesita eso, una solución algo más simple podría funcionar. También puede ver otra respuesta mía donde cubro una pregunta similar: Why choosing JMS for asynchronous solution ?

Answer 5

'Reintentar automáticamente Si usted es un cliente que hace una RMI a un servidor y por alguna razón RMI falla, debe intentarlo usted mismo. Si usara JMS y usted es el cliente, solo enviaría el mensaje JMS. Cuando el servidor no puede ser alcanzado, su mensaje será almacenado y luego entregado cuando el servidor esté nuevamente activo. '

Creo que la respuesta es engañosa.Es resistente en el sentido de que los mensajes enviados a un destino para el que no son consumidores se almacenarán hasta que haya un consumidor para ese mensaje o ese mensaje expire. Esto supone que el agente de JMS es viable.

Si intenta enviar un mensaje a un intermediario que no se puede alcanzar, debe obtener una JMSException y en ese sentido sus mensajes de cliente pueden perderse a menos que su aplicación haga alguna reserva para almacenarlos y vuelva a intentarlo. En este sentido, un cliente de un servidor JMS se comporta de la misma manera que el cliente en un servidor RMI. Todavía perderá el mensaje si ese servidor está caído.