Posibles trampas al usar una cola JMS?

Question

Me han pedido que diseñe e implemente un sistema para recibir un gran volumen de datos de sensores automáticos de una gran cantidad de dispositivos. Esta información se producirá a intervalos regulares y se enviará al servidor como xml en una publicación HTTP. Los dispositivos seguirán reenviando los mismos datos si no reciben un acuse de recibo específico del servidor. Antes de que se inserte en una serie de tablas en la base de datos principal a través de una transacción, es necesario que se produzca algún procesamiento potencialmente pesado de estos datos, y adicionalmente algunos puntos de datos tendrán que ser enrutados para ser redirigidos a otras URL externas.

Estoy planeando usar un servidor de aplicaciones Java (inclinado hacia GlassFish) con un servlet para recibir los datos entrantes. Me gustaría implementar algún tipo de mecanismo de cola para almacenar los datos temporalmente para que la respuesta al sensor no dependa de todo el procesamiento intermedio. Las colas independientes independientes también son un requisito para la pieza de redirección de datos. Después de investigar un poco, las dos opciones principales parecen ser:

1) Instale una base de datos en el servidor de aplicaciones y use tablas para las diversas colas. Las colas serían procesadas por una aplicación Java, ya sea ejecutándose en el servidor de la aplicación o de forma independiente como su propio servicio.

2) Use una solución JMS respaldada por la base de datos para implementar la puesta en cola.

No estoy tan familiarizado con JMS, pero por lo que he leído, parece ser la mejor solución en este caso. El requisito principal es que nunca se pierda ni se pierda ningún dato del sensor de la cola antes de su procesamiento y que se procese más o menos secuencialmente. También nos gustaría que sea más fácil detener el procesamiento de algunas de las colas en ciertos momentos, pero aún así hacer que acumulen datos y que estos mensajes nunca expiren automáticamente.

Con la estrategia 1 es obvio para mí cómo cumplir estos requisitos, pero puede ser menos robusto y escalable, y más complejo de desarrollar que la estrategia 2, ya que tendré que escribir mi propio código multiproceso para manejar el varias colas independientes. Me pregunto cuáles podrían ser las posibles dificultades al usar colas JMS para este fin, ya que nunca antes había trabajado con ellos.

La integridad de los datos es un gran problema, así que necesito asegurarme de que JMS no pueda garantizar la pérdida de datos en caso de reinicio del servidor, corte de energía o cola por algún motivo. Por ejemplo, ¿podría un problema completar las transacciones en la base de datos principal durante un período de tiempo que podría hacer que la JVM se quedara sin memoria, bloquearse y perder todos los datos acumulados? (Este sería el escenario de pesadilla).

Además, me preguntaba si habría alguna forma de pausar el proceso de cola JMS a través de una herramienta de administración del servidor de aplicaciones o ver fácilmente lo que está en la cola (estaría enquistando un objeto que sería el mensaje xml más algunos otros datos, incluida la marca de tiempo recibida, etc.) He leído algunas publicaciones aquí que tratan sobre temas relacionados, pero quería obtener algunos comentarios directos. Básicamente me gustaría saber de instancias (si las hay) donde JMS no es una solución de cola adecuada y si este es uno de esos casos. Cualquier consejo es muy apreciado.

Answer 1

La respuesta de Kaleb habla de los beneficios de JMS con bastante elocuencia, pero ya que estás preguntando sobre las trampas, esto es lo que se me ocurre.

• No todas las implementaciones de JMS son iguales. En teoría, puede usar cualquier implementación que se adapte a sus necesidades, pero a menos que esté preparado para realizar pruebas de carga y pruebas de condición de falla, no puede saber que una implementación en particular no va a fallar en su caso de uso particular.
• La mayoría de los JMS usan un almacén de datos transaccional como una base de datos relacional como su back-end. Esto significa que en lugar de escribir directamente en el almacén de datos con el que está familiarizado, debe confiar en la capa adicional de la implementación JMS entre usted y los mensajes almacenados.
• Si bien el intercambio de implementaciones JMS para encontrar el que se adapta perfectamente a sus necesidades puede parecer un esfuerzo simple debido a la API JMS homogénea, las funciones críticas para el manejo de fallas, monitoreo del servidor JMS y todas las otras cosas interesantes que existen arriba y más allá de la mensajería va a ser una tarea difícil si cambias tu implementación.

Dicho esto, creo que estarías loco si escribes en el DB tú mismo en lugar de ir con JMS. En el primer punto, ActiveMQ es un venerable servidor JMS utilizado en muchos entornos empresariales. En el segundo punto, el hecho es que terminará escribiendo esa capa extra usted mismo para implementar la mensajería, y su código no tendrá el beneficio de miles de ojos (o un conjunto de desarrolladores pagados cuyo único trabajo es para responder a los clientes y asegurarse de que la implementación de JMS sea sólida). En el tercer punto, bueno, lo mismo termina siendo cierto para tu almacén de datos back-end. Use JMS, se ahorrará problemas a la larga.

Answer 2

Si desea utilizar la ruta JMS, un intermediario de mensajes independiente compatible con JMS (separado de su servidor de aplicaciones) sería una buena opción. Los intermediarios de mensajes abarcan desde código abierto libre (como ActiveMQ en http://activemq.apache.org/ o OpenMQ en https://mq.dev.java.net/), hasta soluciones comerciales a gran escala (WebSphere MQ de IBM en http://www-01.ibm.com/software/integration/wmq/ es uno de los más grandes).

Los agentes de mensajes ofrecen una entrega garantizada (siempre que el servidor esté atento y escuchando), y usted puede hacer bastante para garantizar que el sistema sea seguro, incluidos servidores intermediarios de backup integrados y respaldo de energía instantáneo.Las colas de agentes pueden eventualmente quedarse sin espacio si su servidor de aplicaciones no recoge los mensajes, pero puede asignar una gran profundidad de cola (100 de GB) y hacer que el servidor envíe alertas si los mensajes no se procesan y la cola llega un cierto porcentaje

Su aplicación Java se ejecutaría en un servidor diferente por completo, y se conectaría al intermediario y retiraría los mensajes de la cola lo más rápido posible. Si el servidor de la aplicación falla o deja de recoger los mensajes por cualquier otro motivo, el intermediario simplemente mantendrá todos los mensajes en esa cola hasta que el servidor de la aplicación comience a recogerlos nuevamente.