Desde JMS es sólo una especificación, no hay nada que impida una implementación de proporcionar un cierto nivel de persistencia de mensajes en el cliente. Sin embargo, en la práctica, todas las implementaciones (que yo conozco de todos modos) delegan eso al intermediario.
Tenga en cuenta que la mensajería se diseñó originalmente para tener un intermediario en cada nodo de la misma manera que cada nodo también tenía un TCP/IP, LU6.2 u otra pila de transporte. En ese sentido, se suponía que los mensajes eran estrictamente un transporte, no un servicio central como una base de datos. La intención era proporcionar un servicio local que aislara la aplicación de la falta de disponibilidad de la red y también de la gran cantidad de protocolos de transporte síncrono que estaban disponibles. En este modelo, el intermediario era siempre local y la única comunicación de red era entre dos intermediarios.
A lo largo de los años, los mensajes añadieron la capacidad de un cliente, pero esto se trata más de los costos de licencia que de la arquitectura. La conexión del cliente de mensajería reintrodujo una dependencia en la conectividad de red síncrona que el transporte originalmente tenía la intención de proteger la aplicación. Ahora hemos cerrado el círculo como lo ilustra su pregunta: un requisito para una cola local para proteger la aplicación de la falta de disponibilidad de la red. Excepto que ahora la aplicación que requiere una persistencia local para los mensajes es, de hecho, la (supuestamente) aplicación de mensajería asincrónica.
Por supuesto, podríamos crear un mini-broker local para poner mensajes en cola antes de que lleguen al intermediario central. Pero antes de hacer que el código del cliente sea mucho más complejo (e invitar a una recursión infinita de respaldar nuestro mensaje asíncrono con aún más mensajes asíncronos), recomendaría echar un vistazo a la arquitectura de mensajería original: poner el agente local en las aplicaciones que requieren ese nivel de persistencia
Un enfoque para esto es tratar las aplicaciones de los proveedores de servicios de manera diferente que las aplicaciones de consumidor de servicios. Son los proveedores de servicios los que requieren almacenes de mensajes profundos y persistentes y, como a menudo son transaccionales, no se les puede permitir conmutar por error a una instancia diferente del intermediario (en este caso "diferente" como reconoce el administrador de recursos de XA).
Por otro lado, las aplicaciones simples de solicitud/respuesta pueden continuar conectándose anónimamente a través de la red a un nivel ligero de corredores sin colas permanentes. Estas aplicaciones emiten un mensaje de solicitud fuera de syncpoint y esperan la respuesta en una cola dinámica. Si fallan, pueden volver a emitir la solicitud y la respuesta llegará al nuevo nodo. Estos son candidatos ideales para mensajería en red, basada en el cliente, ya que no tienen afinidad con un agente en particular. Mientras exista un salto de red entre las aplicaciones del cliente y del servidor, no hay necesidad de asegurarse de que los clientes conmuten por fallas con los servidores, etc. Los proveedores de servicios tienen corredores locales y los consumidores del servicio tienen dos (o más) intermediarios centrales livianos para conectarse a .
Por supuesto, esto no cumple con todos los requisitos de mensajería asíncrono pero proporciona una solución que proporciona la más alta confiabilidad para los sistemas de registro y aún conserva los costos de licencia permitiendo a los solicitantes de servicios compartir intermediarios centralizados.
Gracias T.Rob, muy informativo! – user567068