java - settitle - ¿Para qué sirve JMS?
interfaz grafica java swing pdf (11)
En mi opinión, JMS y otros sistemas basados en mensajes están destinados a resolver problemas que necesitan:
- Comunicaciones asincrónicas : una aplicación necesita notificar a otro que se ha producido un evento sin necesidad de esperar una respuesta.
- Confiabilidad Asegúrese de entregar el mensaje una vez y solo una vez. Con su enfoque DB debe "reinventar la rueda", especialmente si tiene varios clientes leyendo los mensajes.
- Acoplamiento flojo . No todos los sistemas se pueden comunicar usando una base de datos. Así que JMS es bastante bueno para ser utilizado en entornos heterogéneos con sistemas desacoplados que pueden comunicarse a través de los límites del sistema.
Estoy buscando ejemplos (simples) de problemas para los cuales JMS es una buena solución, y también razones por las cuales JMS es una buena solución en estos casos. En el pasado, simplemente he usado la base de datos como medio para pasar mensajes de A a B cuando el mensaje no puede ser procesado por B inmediatamente.
Un ejemplo hipotético de dicho sistema es que todos los usuarios recién registrados reciban un correo electrónico de bienvenida dentro de las 24 horas posteriores a la inscripción. En aras de la argumentación, suponga que el DB no registra el tiempo cuando cada usuario se registró, sino que una referencia (clave externa) para cada nuevo usuario se almacena en la tabla pending_email. El trabajo del remitente de correo electrónico se ejecuta una vez cada 24 horas, envía un correo electrónico a todos los usuarios en esta tabla y luego elimina todos los registros de correo electrónico pendiente.
Este parece ser el tipo de problema para el que se debe usar JMS, pero no tengo claro qué beneficio tendría JMS sobre el enfoque que describí. Una ventaja del enfoque DB es que los mensajes son persistentes. Entiendo que las colas de mensajes JMS también pueden persistir, pero en ese caso parece haber poca diferencia entre JMS y el enfoque de "base de datos como cola de mensajes" que describí.
¿Qué me estoy perdiendo? - Don
Guido tiene la definición completa. Desde mi experiencia, todos estos son importantes para un buen ajuste.
Uno de los usos que he visto es la distribución de pedidos en almacenes. Imagínese una empresa de suministros de oficina que tenga un buen número de almacenes que suministren grandes oficinas con suministros de oficina. Esos pedidos llegarían a una ubicación central y luego se combinarían para distribuir el almacén correcto. En la mayoría de los casos, los almacenes no tienen o no desean conexiones de alta velocidad, por lo que los pedidos se envían a través de módems de acceso telefónico y aquí es donde entra asíncrono. Las líneas telefónicas no son tan importantes, por lo que la mitad de las órdenes pueden entrar y aquí es donde la fiabilidad es importante.
Hay un bonito artículo con algunos ejemplos aquí: http://www.winslam.com/laramee/jms/index.html
JMS en combinación con JTA (Java Transaction API) y JPA (API de persistencia de Java) puede ser muy útil. Con una anotación simple puede poner varias acciones de base de datos + envío / recepción de mensajes en la misma transacción. Entonces, si uno de ellos falla, todo se revierte utilizando el mismo mecanismo de transacción.
JMS es una API utilizada para transferir mensajes entre dos o más clientes. Sus especificaciones se definen bajo JSR 914.
The major advantage of JMS is the decoupled nature of communicating
entities - Sender need not have information about the receivers.Other advantages
include the ability to integrate heterogeneous platforms, reduce system
bottlenecks, increase scalability, and respond more quickly to change.
Los JMS son solo una especie de interfaces / API y las clases concretas deben implementarse. Estos ya están implementados por varias organizaciones / proveedores. se llaman proveedores de JMS. Ejemplo es WebSphere de IBM o FioranoMQ de Fiorano Softwares o ActiveMQ de Apache, HornetQ, OpenMQ, etc. Otras expresiones utilizadas son Admin Objects (Temas, Queues, ConnectionFactories), JMS producer / Publisher, JMS client y el mensaje en sí.
Entonces, respondiendo a su pregunta, what is JMS good for? Me gustaría dar un ejemplo práctico para ilustrar su importancia.
Dia de cambio
Hay esta característica llamada LVC (Caché de último valor)
En los precios de las acciones de Trading los publica un editor a intervalos regulares. Cada acción tiene un tema asociado al que se publica. Ahora bien, si sabe qué tema es, debe saber que los mensajes no se guardan como si fueran colas. Los mensajes se publican a los suscriptores vivos en el momento en que se publicó el mensaje (Excepción que son los suscriptores de Durables que reciben todos los mensajes publicados desde el momento en que se crearon pero luego no queremos obtener precios de acciones demasiado antiguos que descarten la posibilidad de usándolo). Entonces, si un cliente quiere saber el precio de una acción, crea un suscriptor y luego tiene que esperar hasta que se publique el siguiente precio de la acción (que nuevamente no es lo que queremos). Aquí es donde LVC entra en la imagen. Cada mensaje LVC tiene una clave asociada. Si se envía un mensaje con una clave LVC (para un stock en particular) y luego otro mensaje de actualización con la misma clave, el último anula el anterior. Cuando un suscriptor se suscribe a un tema (que tiene LVC habilitado), el suscriptor recibirá todos los mensajes con distintas claves de LVC. Si mantenemos una clave distinta para cada empresa que cotiza en bolsa, cuando el cliente se suscriba obtendrá el precio de cotización más reciente y, finalmente, todas las actualizaciones.
Por supuesto, este es uno de los factores que hacen que JMS sea tan poderoso.
JMS y la mensajería en realidad se trata de 2 cosas totalmente diferentes.
- publicar y suscribirse (enviar un mensaje a tantos consumidores como le interese, un poco como enviar un correo electrónico a una lista de correo, el remitente no necesita saber quién está suscrito
- Equilibrio de carga confiable de alto rendimiento (colas de mensajes)
Vea más información sobre cómo una cola se compara con un tema
El caso del que está hablando es el segundo caso, donde sí puede usar una tabla de base de datos para simular una cola de mensajes.
La principal diferencia es que una cola de mensajes JMS es un equilibrador de carga altamente concurrente de alto rendimiento diseñado para un gran rendimiento; En general, puede enviar decenas de miles de mensajes por segundo a muchos consumidores simultáneos en muchos procesos e hilos. La razón de esto es que una cola de mensajes es básicamente muy asíncrona: un buen proveedor de JMS enviará mensajes por adelantado a cada consumidor para que haya miles de mensajes disponibles para ser procesados en la RAM tan pronto como haya un consumidor disponible. Esto conduce a un rendimiento masivo y una latencia muy baja.
por ejemplo, imagina escribir un equilibrador de carga web usando una tabla de base de datos :)
Cuando se usa una tabla de base de datos, generalmente un hilo tiende a bloquear toda la tabla, por lo que se tiende a obtener un rendimiento muy bajo cuando se intenta implementar un equilibrador de carga de alto rendimiento.
Pero como la mayoría del middleware, todo depende de lo que necesites; si tiene un sistema de bajo rendimiento con solo unos pocos mensajes por segundo, puede usar una tabla de la base de datos como cola. Pero si necesita baja latencia y alto rendimiento, entonces las colas JMS son muy recomendables.
La implementación de JMS es "push", en el sentido de que no tiene que sondear la cola para descubrir nuevos mensajes, pero registra una devolución de llamada que se invoca tan pronto como llega un nuevo mensaje.
La principal ventaja es desacoplar sistemas no relacionados en lugar de hacer que compartan bases de datos comon o que creen servicios personalizados para pasar datos.
Los bancos son un buen ejemplo, con mensajes intradía que se utilizan para pasar los cambios de datos en vivo a medida que ocurren. Es muy fácil para el sistema de origen lanzar un mensaje "sobre la pared"; La desventaja es que hay muy poco en la forma de contrato entre estos sistemas, y usted normalmente ve la hospitalización siendo implementada por el lado del consumidor. Está casi demasiado débilmente acoplado.
Otras ventajas se deben a la compatibilidad con JMS para muchos servidores de aplicaciones, etc. y todas las herramientas a su alrededor: durabilidad, monitoreo, informes y aceleración.
La solución ''base de datos como cola de mensajes'' puede ser pesada para la tarea. La solución JMS está menos acoplada, ya que el remitente del mensaje no necesita saber nada sobre el destinatario. Esto podría lograrse con alguna abstracción adicional en la ''base de datos como cola de mensajes'', así que no es una gran ganancia ... Además, puede usar la cola de una manera ''publicar y suscribirse'' que puede ser útil dependiendo de qué estás tratando de lograr. También es una buena manera de desacoplar aún más sus componentes. Si toda su comunicación está dentro de un sistema y / o tiene un registro que está inmediatamente disponible para una aplicación es muy importante, su método parece bueno. Si se está comunicando entre sistemas separados, JMS es una buena opción.
Una de las ventajas de JMS es permitir el procesamiento asíncrono que también puede realizarse mediante una solución de base de datos. Sin embargo, los siguientes son algunos otros beneficios de JMS sobre la solución de base de datos
a) El consumidor del mensaje puede estar en una ubicación remota. La exposición de la base de datos para acceso remoto es peligrosa. Puede solucionar esto proporcionando un servicio adicional para leer mensajes de la base de datos, que requiere más esfuerzo.
b) En el caso de la base de datos, el consumidor del mensaje debe sondear la base de datos en busca de mensajes donde JMS proporciona una devolución de llamada cuando llega un mensaje (como se menciona sk)
c) Equilibrio de carga: si hay una gran cantidad de mensajes, es fácil tener un grupo de procesadores de mensajes en JMS.
d) En general, la implementación a través de JMS será más simple y requerirá menos esfuerzo que la ruta de la base de datos.
para abordar el comentario original. lo que se describió originalmente es la esencia del JMS (punto a punto). los beneficios de JMS son, sin embargo:
no necesita escribir el código usted mismo (y posiblemente arruine la lógica para que no sea tan persistente como cree que es). también, el impl de terceros podría ser más escalable que el simple enfoque de base de datos.
jms maneja publicar / suscribir, lo cual es un poco más complicado que el ejemplo punto a punto que usted dio
no está vinculado a una implementación específica, y puede cambiarlo si sus necesidades cambian en el futuro, sin problemas con su código java.