Si desea utilizar un producto de cola para mensajes duraderos en Windows, ejecutando .NET 2.0 y superior, ¿qué alternativas existen actualmente a MSMQ? Sé de ActiveMQ (http://activemq.apache.org/) y he visto referencias a WSMQ (apuntando a http://wsmq.net), pero el sitio parece estar fuera de servicio.¿Alternativas de cola a MSMQ en Windows?
¿Hay alguna otra alternativa?
No puedo comenzar a decir suficientes cosas buenas sobre Tibco EMS: una implementación de la especificación de mensajería Java JMS. Tibco EMS tiene un excelente soporte para clientes .NET, incluido Compact Framework .NET en WinCE. (También tienen bibliotecas de cliente C)
Así que si está creando una aplicación distribuida heterogénea que involucre un código de mensajería que se ejecute en Windows, Unix (AIX/Solaris), Linux o Mac OS X, entonces Tibco EMS es el boleto.
Compruebe hacia fuera mi artículo aquí:
Using JMS For Distributed Software Development
Solía trabajar en Microsoft y hecho un poco de aplicación con MSMQ mientras esté allí. Pero ya sabes, Microsoft solo se preocupa por Windows. Dependen de terceros para proporcionar clientes de MSMQ a otras plataformas. Mi encuentro con Tibco EMS fue una experiencia mucho mejor. Era muy evidente que Tibco entendía los mensajes mucho más que Microsoft. Y Tibco se esforzó en apoyar diversas consolidaciones de clientes. Es por eso que finalmente cambiaron el nombre del producto de Tibco JMS a Tibco EMS (Enterprise Messaging Service).
Y construí sistemas de software heterogéneos alrededor de Tibco EMS. Los clientes de Winform C# .NET enrollados interactúan con Java/JBoss de nivel medio a través de la mensajería Tibco EMS. (Y también tienen WinCE ordenadores integrados industriales que utilizan el cliente .NET Compact Framework Tibco.)
¿Qué hay de SQL 2005's service broker?
Puede que no sea un consejo de "mejores prácticas" aquí ... pero en base a las necesidades y experiencia de la vida real: tenemos sistema distribuido, 60 cajas ejecutando cada 10 clientes todos hacen tarea X, y necesitan tomar la siguiente tarea de una cola. La cola se está alimentando desde otro "cliente" ...
Utilizamos la comunicación entre procesos, usamos MSMQ, probamos el intermediario de servicios ... Simplemente no funciona a largo plazo porque está dando lejos del control de su aplicación a Microsoft. Funciona muy bien siempre que sus necesidades estén satisfechas. se convierte en un infierno cuando necesitas algo que no es compatible.
La mejor solución para nosotros fue: utilizar una tabla de base de datos SQL como la cola. No reinvente la rueda allí, ya que cometerá errores (bloqueos). Hay información sobre cómo hacerlo, es muy fácil y manejamos más de 200,000 mensajes por 24H (con 60x10 = 600 lecturas concurrentes y escrituras en la cola). Es decir, además de la misma manipulación del resto de las cosas aplicación de servidor SQL ...
Algunas razones por las MSMQ no funciona:
Cuando es necesario cambiar la lógica de la cola de no FIFO, pero algo así como "el mensaje RED más antiguo" o "el mensaje AZUL más antiguo" no puede hacerlo. (Sé lo que las personas dirán, puede hacerlo teniendo una cola roja y una cola azul ... .Pero qué sucede si el número/tipo de colas es dinámico en función de la forma en que se administra la aplicación y cambia a diario ?)
Agrega un punto de falla y una pesadilla de implementación (la cola es un punto de falla y debe tratar de establecer los permisos correctos en todos los cuadros para leer/escribir mensajes, etc. 'en el software Enterprise que paga sangre para este tipo de cosas). servidor SQL ... todos los clientes están escribiendo/lectura ya desde la base de datos, es sólo uno más mesa ..
El uso de SQL Server no es un reemplazo de todas las características de MSMQ. MSMQ hecho correctamente significa que cada una de sus 60 cajas puede funcionar mientras el servidor central está desconectado (siempre que se entreguen suficientes mensajes para mantenerlos ocupados). Para su escenario (distribución de trabajo en un escenario en línea) SQL tiene sentido, pero no estoy seguro de que sea una "alternativa a MSMQ" general. –
Es una cola, ¿por qué quieres una cola FIFO sin ninguna? Eso es lo que es una cola. – Liam
Sin mencionar que 200k mensajes en 24 h no son nada en algunos sistemas. – zaitsman
Si el costo no es un problema (También hay una SKU Express) y luego tomar una mirada al gorila de 800,000 libras. WebSphere MQ (serie MQ). Se ejecuta en prácticamente cualquier plataforma y admite tantos gestores de colas y patrones de mensajería diferentes que realmente no es apropiado enumerarlos aquí.
Y puede valer la pena señalarlo explícitamente: IBM proporciona una biblioteca .NET Client para WebSphere MQ. Cualquier aplicación .NET puede enqueue un mensaje, y otra aplicación en otra plataforma (por ejemplo, una aplicación Java en un mainframe) puede dequeue. – Cheeso
Usamos Websphere MQ en 'VMS' (usando' C') - es muy robusto – Matt
Por qué no usar ActiveMQ? :)
Si la alta disponibilidad es importante, vale la pena mirar Amazon SQS. No hay mucha sobrecarga adicional si los mensajes provienen de diferentes ubicaciones físicas. Barato y escalable!
Redis es otra raza caliente en esta plataforma. Verifique con su implementación de cola basada en conjunto y también el patrón Pub/Sub. Se ve prometedor
The RabbitMQ framework parece haber sido pasado por alto aquí. Si a la gente todavía le importa, tiene una base de código .NET 2.0 y viene con un enlace WCF similar a netMsmqBinding. Naturalmente, el enlace requiere al menos .NET 3.0 y tiene más características que el netMsmqBinding incorporado. Además de todo, es mono amigable. Vale la pena mirar.
Además: Requiere una configuración no trivial de Erlang. –
@DanEsparza Cada vez que he tenido que instalar Erlang, era muy simple. –
ese sitio (http://wsmq.net) no está caído, pero el dominio está a la venta. significa que WSMQ es RIP! –