Pregunta 1: ¿Es correcta mi comprensión básica de JMS?

Vamos a obtener las terminologías bien primero. No se puede decir JMS Provider must be running porque el proveedor es una entidad que ha construido el servidor JMS y es el servidor JMS el que debe estar ejecutándose. Por lo tanto, cuando decimos JMS, nos referimos a un conjunto de API (interfaces más técnicas) que implementan los proveedores. Así que básicamente los proveedores escriben su propia implementación de JMS. Por ejemplo, Active MQ is a JMS server que es proporcionado por Apache(provider)

Mi suposición al publicar es que el proveedor de JMS simplemente espera hasta que se publique un mensaje, luego lo almacena en una cola (respaldada por memoria o base de datos, dependiendo de la implementación).

Cierto hasta Cierto punto. Hay diferentes modelos que se siguen. El servidor JMS mantiene un socket abierto. Cada vez que un cliente remitente tiene que enviar un mensaje, simplemente abre una conexión al socket y envía el mensaje. Cómo se comporta receive es completamente diferente. Tienes pully push. En push el servidor enviará los mensajes al cliente live receiver tan pronto como reciba el mensaje. Esto también se llama modo asíncrono. En el modelo pull, el receptor del cliente envía una solicitud al servidor para obtener mensajes (modo síncrono).

Recibe (típicamente) bloquear si no hay mensajes disponibles?

Como mencioné en el punto anterior, dependerá del modelo que esté utilizando. El receptor se bloqueará en el modelo de extracción ( recepción síncrona). También esto sucede en Session thread, no en el hilo principal.

Si es así, ¿cómo se logra el bloqueo? ¿El cliente sondea continuamente los mensajes?

Sí, el cliente sondeará continuamente en caso de modelo de extracción. Generalmente hay un tiempo de espera después del cual el cliente será terminado.

Si no es así, ¿cómo se asegura de que los mensajes se reciban de manera oportuna, sin afectar el rendimiento?

Use modo asíncrono. Simplemente tienes para registrar un MessageListener y recibirá un mensaje cuando se anule onMessage(Mensaje msg) cuando haya disponibilidad de mensajes en el servidor.

Pregunta 3: ¿Cómo escala JMS?

Es realmente una pregunta de la que los proveedores deben preocuparse. Cuando usted dice que un mensaje es recibido por todos los suscriptores que se refiere a PUBSUB modelo de comunicación (otro ser PTP ). En PUBSUB se entregará el mensaje enviado a un tema a todos los suscriptores suscritos a ese tema.

Pregunta 3b: ¿Cómo garantiza una implementación de JMS una entrega confiable en un entorno escalado?

Fiabilidad? No siempre. Una vez más, esto depende del caso de uso. Puede tener mensajes persistentesasí como mensajes no persistentes. En caso de mensajes persistentes, los mensajes se almacenan en la base de datos (archivo u otros) y se garantiza su entrega. En caso de mensajes no persistentes no existe tal garantía. Servidor el fallo puede resultar en la pérdida del mensaje.

JMS admite el consumo de mensajes con un método síncrono (recibir con y sin tiempo de espera bloqueando tu hilo) o con una devolución de llamada impulsada por eventos (oyente de mensajes asíncronos)).

Puede decidir qué método se adapta mejor a sus necesidades, pero también puede tener que echar un vistazo a la implementación real. Por ejemplo, algunas implementaciones de JMS hacen un recorrido de red para receive () y por lo tanto se usan mejor con un tiempo de espera o con el receptor.

Con el hilo de escucha de mensajes el comportamiento y la pausa de la recepción de mensajes no se controlan tan fácilmente como con una llamada de recepción de bloqueo. Por lo general, la mayor parte del control se logra al tener su propio grupo de bloqueo de llamadas receive() con tiempos de espera, enviando a sus trabajadores.

Creo que la diferencia entre la Cola y el Tema debe mencionarse, ya que hay diferencias importantes en la forma en que se entregan los mensajes.

Cola: solo un cliente recibirá un mensaje. Para escalar, por ejemplo, puede tener 10 clientes conectados a la misma cola - pero sólo uno de ellos recibirá un mensaje en particular. Si no hay clientes conectados, el mensaje permanecerá en la cola hasta que alguien se conecte o el mensaje se agote.

Tema: todos los clientes recibirán un copia de cada mensaje. Normalmente se usa en un escenario de suscriptor donde muchos endpoints están potencialmente interesados en cada mensaje. Un suscriptor duradero puede incluso estar inactivo por un tiempo; el mensaje se mantendrá hasta que el suscriptor vuelva a estar activo o el mensaje se agote. Si no hay clientes conectados y no hay suscriptores duraderos, el mensaje se eliminará.

Hay dos tipos de dominios de mensajería en JMS.

1. Pcualquier-To-Pcualquier(PTP) Dominio de Mensajería
2. Dominio de Mensajería del Editor/Suscriptor

En el modelo PTP , un mensaje se entrega a un solo receptor. Aquí, la Cola es usada como un Message Oriented Middleware (MAMÁ).

La Cola es responsable de retener el mensaje hasta que el receptor esté listo.

En PTP modelo, no hay dependencia de tiempo entre el emisor y el receptor.

En el modelo Pub / Sub , se envía un mensaje a todos los suscriptores. Es como la radiodifusión. Aquí, Topic se utiliza como un middleware orientado a mensajes que es responsable de mantener y entregar mensajes.

En el modelo PTP, hay dependencia de tiempo entre el editor y el suscriptor.

Programación JMS Modelo

Fuente

Message Driven Bean (MDB)

• MDB es un frijol que contiene lógica de negocios. Pero, se invoca al pasar el mensaje. Por lo tanto, es como JMS Receptor.
• MDB recibe asíncronamente un mensaje y lo procesa.
• MDB recibe un mensaje de la cola o del tema.
• MDB es como un bean de sesión sin estado que encapsula una lógica de negocio y no mantener un estado de la haba.