JMS (Java Message Service) es la solución tecnológica ofertada por Java para sistemas de comunicación asíncronos.
Arquitectura de JMS
En la arquitectura JMS participan las siguientes entidades:
- Clientes JMS. Son las aplicaciones que envian y/o reciben mensajes a través de JMS.
- Mensajes. Son los datos intercambiados.
- Destinos JMS. Son los almacenes intermedios donde se almacenan los mensajes.
Los servicios de mensajería ofrecen dos tipos de destinos:
- Colas (tipo queue). Una aplicación (productor) genera un mensaje, lo deposita en la cola y cuando la segunda aplicación (consumidor) se conecta al servicio de mensajería, recoge el mensaje. Habitualmente en una cola sólo participan un productor y un consumidor, pero podrían existir varios productores y varios consumidores colaborando (sistemas de alto rendimiento). En este caso lo fundamental es que cada mensaje se procesa una única vez, no importa qué consumidor lo procese. Los mensajes salen de la cola en orden de llegada, el primero que se recibió es el primero que se recoge (FIFO).
- Publicador/Suscriptores (tipo topic). Una aplicación (publicador) genera un mensaje, lo publica en el servicio JMS y lo reciben todas las aplicaciones (suscriptores) que esten suscritas al servicio JMS en que se publicó el mensaje. Habitualmente en una cola participa un publicador y muchos suscriptores, pero podrían existir varios publicadores.
Dado que los servicios JMS son asíncronos, los mensajes son almacenados en las colas (tipo queue ó tipo topic) hasta ser recibidos por sus destinatarios. Se debe garantizar que ningún mensaje se pierda incluso cuando el servidor JMS se apague súbitamente. Por ello, los servidores JMS suelen ofrecer la posibilidad de persistir los mensajes en algún medio no volatil como una base de datos.
Seguridad
Como en cualquier mecanismo de comunicación, la seguridad es un aspecto fundamental que siempre debe tenerse en cuenta. Son posibles dos acciones:
Autenticación. Los servidores JMS ofrecen mecanismos para autenticar tanto a los depositantes como a receptores de los mensajes, dado que de otro modo podrían entrar en las colas de mensajes de procedencia desconocida. Lo habitual son comunicaciones SSL. Siempre es posible que las aplicaciones que se comunican a través e JMS implementen sus propios sistemas de autenticación, lo que las hace más interdependientes, pero puede ser necesario si el servidor JMS no es confiable.
Cifrado. Los sistemas de persistencia antes mencionados almacenan los mensajes en una BBDD, lo que los expone a consultas indeseables por parte de terceros. Por ello es siempre conveniente que las aplicaciones cifren los datos intercambiados. El mecanismo de cifrado también se puede dejar en manos del servidor JMS o de la BBDD que persista los mensajes, si ámbos sistemas son confiables.
Disponibilidad
Cualquier sistema de comunicaciones síncrono que pase a ser asíncrono, pasará de dos a tres entidades participando en el intercambio de datos. Si se desea garantizar la tolerancia a fallos 24x7 deberá garantizarse la tolerancia a fallos tanto en las aplicaciones que intercambian los datos como en el servidor JMS.
buena info, pero tengo la duda de por que mi consumer trata de procesar varios mensajes al mismo tiempo, y esto me crea un error al hacer un insert en mi sistema
ResponderEliminar