Respuestas:
JMS (ActiveMQ es una implementación de intermediario JMS) se puede utilizar como un mecanismo para permitir el procesamiento de solicitudes asíncronas. Es posible que desee hacer esto porque la solicitud tarda mucho en completarse o porque varias partes pueden estar interesadas en la solicitud real. Otra razón para usarlo es permitir que varios clientes (potencialmente escritos en diferentes idiomas) accedan a la información a través de JMS. ActiveMQ es un buen ejemplo aquí porque puede usar el protocolo STOMP para permitir el acceso desde un cliente C # / Java / Ruby.
Un ejemplo del mundo real es el de una aplicación web que se utiliza para realizar un pedido para un cliente en particular. Como parte de hacer ese pedido (y almacenarlo en una base de datos) es posible que desee llevar a cabo una serie de tareas adicionales:
Para hacer esto, el código de su aplicación publicaría un mensaje en una cola JMS que incluye una identificación de pedido. Una parte de su aplicación que escucha la cola puede responder al evento tomando el ID de pedido, buscando el pedido en la base de datos y luego haciendo ese pedido con otro sistema de terceros. Otra parte de su aplicación puede ser responsable de tomar el ID de pedido y enviar un correo electrónico de confirmación al cliente.
Úselos todo el tiempo para procesar operaciones de larga duración de forma asincrónica. Un usuario web no querrá esperar más de 5 segundos para que se procese una solicitud. Si tiene uno que dura más que eso, un diseño es enviar la solicitud a una cola e inmediatamente enviar una URL que el usuario puede verificar para ver cuándo finaliza el trabajo.
Publicar / suscribirse es otra buena técnica para desacoplar remitentes de muchos receptores. Es una arquitectura flexible, porque los suscriptores pueden ir y venir según sea necesario.
He tenido muchos usos increíbles para JMS:
Comunicación por chat web para servicio al cliente.
Registro de depuración en el servidor. Todos los servidores de aplicaciones transmitieron mensajes de depuración en varios niveles. Entonces se podría iniciar un cliente JMS para buscar mensajes de depuración. Claro que podría haber usado algo como syslog , pero esto me dio todo tipo de formas de filtrar la salida en función de la información contextual (ecualizador por nombre del servidor de la aplicación, llamada a la API, nivel de registro, ID de usuario, tipo de mensaje, etc.). También coloreé la salida.
Depurar el registro en el archivo. Igual que el anterior, solo se extrajeron piezas específicas mediante filtros y se registraron en el archivo para el registro general.
Alertas Una vez más, una configuración similar al registro anterior, observando errores específicos y alertando a las personas por diversos medios (correo electrónico, mensaje de texto, mensajería instantánea, mensaje emergente de Growl ...)
Configuración y control dinámicos de clústeres de software. Cada servidor de aplicaciones emitiría un mensaje "configúreme", luego un demonio de configuración que respondería con un mensaje que contiene todo tipo de información de configuración. Más tarde, si todos los servidores de aplicaciones necesitaran cambiar sus configuraciones a la vez, se podría hacer desde el demonio config.
Y lo habitual: transacciones en cola para actividades retrasadas, como facturación, procesamiento de pedidos, aprovisionamiento, generación de correo electrónico ...
Es excelente en cualquier lugar donde desee garantizar la entrega de mensajes de forma asincrónica.
Distribuido (a) computación síncrona.
Un ejemplo del mundo real podría ser un marco de notificación de toda la aplicación, que envía correos electrónicos a las partes interesadas en varios puntos durante el curso del uso de la aplicación. Por lo tanto, la aplicación actuaría como un Producercreando un Messageobjeto, poniéndolo en un particular Queuey avanzando.
Habría un conjunto de Consumercorreos electrónicos que se suscribirían a la Queuepregunta en cuestión y se encargarían de manejar el Messageenvío. Tenga en cuenta que durante el curso de esta transacción, los Producers se desacoplan de la lógica de cómo Messagese manejaría un determinado .
Los marcos de mensajería (ActiveMQ y similares) actúan como una columna vertebral para facilitar tales Messagetransacciones al proporcionar MessageBrokers.
Lo he usado para enviar intercambios intradía entre diferentes sistemas de gestión de fondos. Si desea obtener más información acerca de lo que es una excelente tecnología de mensajería, puedo recomendar el libro " Patrones de integración empresarial ". Hay algunos ejemplos de JMS para cosas como solicitar / responder y publicar / suscribirse.
La mensajería es una excelente herramienta para la integración.
Lo usamos para iniciar el procesamiento asincrónico que no queremos interrumpir o entrar en conflicto con una transacción existente.
Por ejemplo, supongamos que tiene una lógica costosa y muy importante como "comprar cosas", una parte importante de comprar cosas sería "notificar a la tienda de cosas". Hacemos que la llamada de notificación sea asíncrona para que cualquier lógica / procesamiento que esté involucrado en la llamada de notificación no bloquee o compita con recursos con la lógica comercial de compra. Resultado final, la compra se completa, el usuario está contento, recibimos nuestro dinero y debido a que la cola está garantizada, la tienda recibe una notificación tan pronto como se abre o cuando hay un nuevo artículo en la cola.
Lo he usado para mi proyecto académico, que era un sitio web minorista en línea similar a Amazon. JMS se utilizó para manejar las siguientes características:
Tuvimos múltiples clientes remotos también implementados conectados al servidor principal. Si la conexión está disponible, utilizan para acceder a la base de datos principal o si no utilizan su propia base de datos. Para manejar la consistencia de los datos, implementamos el mecanismo 2PC. Para esto, utilizamos JMS para intercambiar los mensajes entre estos sistemas, es decir, uno que actúa como coordinador que iniciará el proceso enviando un mensaje en la cola y otros responderán en consecuencia enviando nuevamente un mensaje en la cola. Como otros ya han mencionado, esto fue similar al modelo pub / sub.
He visto JMS utilizado en diferentes proyectos comerciales y académicos. JMS puede entrar fácilmente en su imagen, siempre que desee tener un sistema distribuido totalmente desacoplado. En términos generales, cuando necesita enviar su solicitud desde un nodo, y alguien en su red se encarga de ello sin / con darle al remitente información sobre el receptor.
En mi caso, he usado JMS en el desarrollo de un middleware orientado a mensajes (MOM) en mi tesis, donde se generan tipos específicos de objetos orientados a objetos en un lado como su solicitud, y compilados y ejecutados en el otro lado como su respuesta .
Apache Camel usado junto con ActiveMQ es una excelente manera de hacer patrones de integración empresarial
Estamos utilizando JMS para la comunicación con sistemas en una gran cantidad de sitios remotos a través de redes poco confiables. El acoplamiento suelto en combinación con mensajes confiables produce un panorama estable del sistema: cada mensaje se enviará tan pronto como sea técnicamente posible, los problemas más grandes en la red no tendrán influencia en todo el panorama del sistema ...