Estamos usando ActiveMQ 5.2 como nuestra implementación preferida y la elegimos hace un tiempo. Funciona lo suficientemente bien para nuestro uso en este momento. Desde hace un tiempo, me preguntaba qué otras implementaciones de Java Message Service están en uso y por qué. Seguramente hay más de unos pocos.¿Qué implementación de JMS usa?
En uno de los proyectos recientes en los que estuve, utilizamos Sonic MQ. Buena implementación general con buenas conexiones a .NET.
Tuvimos algunos problemas de escalabilidad, pero debo admitir que los requisitos de escalabilidad eran muy estrictos: si puedo recordar correctamente, algo así como 20,000 líos por segundo sin retrasos permitidos entre los 200 clientes diferentes (cada cliente tenía para recibir cada mensaje al mismo tiempo).
He usado JBossMQ, que viene con el servidor de aplicaciones JBoss hasta la versión 4, y que es sólido pero limitado. JBoss Messaging fue el reemplazo, viene con JBossAS 5 y es una gran mejora.
ActiveMQ Tengo una verdadera aversión por. Los desarrolladores parecen haber optado por el rendimiento y las funciones en detrimento de la estabilidad, y es increíblemente problemático. Dado que es el tejido JMS para Gerónimo, me preocupa.
Nuestra experiencia fue que las versiones 3 y 5 son significativamente mejores que 4 para ActiveMQ. –
... en términos de bugginess, quise escribir. –
Intenté 5.1 cuando salió, y encontré que la integración de Spring estaba rota de maneras muy simples y obvias, mientras que 5.0 funcionaba bien en ese sentido. Ya no tengo confianza en el régimen de prueba de ActiveMQ. – skaffman
Confiamos en AMQ (5.1) a través del framework Camel, y no ha habido ningún problema. AMQ 4 era un poco más sospechoso.
TIBCO EMS. Es un servicio de mensajes comerciales con Java/JMS, C, .net y otras vinculaciones para él.
Sun's Open source OpenMQ (https://mq.dev.java.net/). Puede obtener soporte gratuito y pago para el mismo.
Vea esta publicación en el blog acerca de algunas comparaciones con ActiveMQ, etc. - http://alexismp.wordpress.com/2008/06/06/openmq-the-untold-story/.
He oído que OpenMQ es más estable.
ActiveMQ es más flexible. como en, puedes usarlo con más idiomas. Probablemente haya más personas en la lista de correo de ActiveMQ que OpenMQ.
IBM WebSphere MQ 5 y 6 Active MQ 5.2.0
También puedes ver Micro gestor_colas en http://codingjunky.com/page5/page4/page4.html Es pequeño, fácil de instalar y utilizar para proyectos más pequeños.
Proveedor WebLogic JMS cuando se utiliza WebLogic. Funciona genial.
Gracias. ¿Esto sigue siendo válido ahora? Necesitamos implementar una cola en un entorno weblogic. Estoy pensando si debería elegir ActiveMQ o Weblogic JMS interno? – Jay
Estamos utilizando SonicMQ, JBossMQ y el "micro broker" de Lotus Expeditor Integrator. Los estamos utilizando para diferentes propósitos:
-JBossMQ se usa internamente y para comunicarnos con todas nuestras aplicaciones Java EE que se ejecutan en JBoss. -Lotus Expeditor se usa en "sitios remotos" donde solo tenemos recursos limitados y personal de TI -SonicMQ es nuestra red troncal de mensajería, la usamos para conectar sistemas centrales, pero también para conectar sistemas remotos en aprox. 1000 sitios.
Estamos teniendo buenas experiencias con todos ellos, pero nuestra experiencia es también que con un entorno más complejo, usted tiene que hacer una administración más activa del sistema de mensajería. Esto se hizo especialmente cierto con SonicMQ en nuestro sitio :-). Desde la perspectiva del rendimiento, hicimos las mejores experiencias con SonicMQ, especialmente en la mensajería persistente basada en cola.
He usado ActiveMQ en producción desde hace un par de años, pero nunca me gustó su estabilidad (especialmente con la capacidad de clúster). Nunca miró hacia atrás después de cambiar a OpenMQ. Es posible que desee buscar en RabbitMQ o ZeroMQ.
Antes de profundizar en JMS, considere AMQP también, podría ser un nuevo estándar. Proveedores de JMS con los que trabajé (en diversos grados):
TIBCO EMS: muy rápido y robusto, buen soporte de API, Java amigable, C API nativa existe. La mejor opción comercial que he usado.
Websphere MQ (y su implementación JMS) - entonces, entonces. Pub/sub no exactamente rápido, muchas opciones de configuración y opciones son "extrañas" y demasiado complejas a partir de la larga historia de ese producto. Basta con mirar a la cantidad de documentación ...
Solace JMS - un rendimiento muy alto (! Al agente de JMS se basa en el hardware), buenas opciones de protocolos de conexión (MQTT, AMQP, XML sobre HTTP como protocolos de administración)
Fiorano MQ - solía ser agresivos en la comercialización, pero perdió una gran cantidad de la cuota de mercado, la madurez se refiere
de sonic MQ - producto sólido, también es compatible con una API C
Active MQ - si quieres ir con una producto de código abierto (soporte no costoso, gran comunidad, productos complementarios limitados, funciones empresariales limitadas) esto es probable bly tu mejor opción. Funciona de la caja y es la columna vertebral de varias herramientas como Apache Camel, por ejemplo.
¿Cuál es la diferencia entre solace jms y tibco ems? La razón por la que pregunto, estamos ejecutando tibco ems en solace hw, pero es tibco ems broker. Supongo que solace jms es una bestia completamente diferente. – sloven
¿Está seguro de que está ejecutando EMS en un hardware Solace? Esa sería una combinación extraña. TIBCO EMS es solo software (hay otra versión de hardware) y Solace es hardware por defecto (también tienen una VM de software para probar). Y sí, Solace JMS y TIBCO JMS (= EMS) son diferentes: empresas diferentes, pero ambas admiten la misma API (JMS) –
Sí ... He visto esta configuración en * varios * lugares. Compran la mensajería infra (hw) de Solace y ejecutan tibco sobre ella ... Para todas las aplicaciones java utilizan bibliotecas tibco y para cualquier latencia realmente baja escriben C++ que usa el nivel de sistema de consuelo ... Creo que estamos hablando de esto último Si el intermediario está integrado en hw, necesita ir a bajo nivel para interactuar con él, tiene sentido. – sloven
¿Hay alguna implementación que pueda escalar tan alto? – cdoe
@Mani: No tengo los detalles sobre la configuración exacta o la arquitectura del sistema de colas que se implementó porque no formaba parte del equipo de desarrollo de middleware, pero sí, terminamos alcanzando esos niveles de rendimiento con Sonic MQ. Sin embargo, tomó varias iteraciones probando diferentes esquemas de configuración de hardware y cola. –