Alternative alla coda a MSMQ su Windows?[Chiuso]

StackOverflow https://stackoverflow.com/questions/37579

  •  09-06-2019
  •  | 
  •  

Domanda

Se si desidera utilizzare un prodotto di accodamento per la messaggistica durevole in Windows, con .NET 2.0 e versioni successive, quali alternative esistono oggi a MSMQ?Conosco ActiveMQ (http://activemq.apache.org/) e ho visto riferimenti a WSMQ (che indica http://wsmq.net), ma il sito sembra non essere disponibile.

Ci sono altre alternative?

È stato utile?

Soluzione

Non posso iniziare a dire abbastanza cose positive su Tibco EMS, un'implementazione delle specifiche di messaggistica Java JMS.Tibco EMS offre un eccellente supporto per i client .NET, incluso Compact Framework .NET su WinCE.(Hanno anche librerie client C.)

Quindi, se stai creando un'applicazione distribuita eterogenea che coinvolge codice di messaggistica in esecuzione su Windows, Unix (AIX/Solaris), Linux o Mac OS X, allora Tibco EMS è la soluzione giusta.

Dai un'occhiata al mio articolo qui:

Utilizzo di JMS per lo sviluppo di software distribuito

Lavoravo in Microsoft e mentre ero lì ho fatto alcune implementazioni con MSMQ.Ma si sa, Microsoft si occupa solo di Windows.Dipendevano da terze parti per fornire client MSMQ ad altre piattaforme.Il mio incontro con Tibco EMS è stata un'esperienza decisamente migliore.Era evidente che Tibco capisse la messaggistica molto più di Microsoft.E Tibco si è impegnata a supportare da sola le diverse associazioni dei clienti.Questo è il motivo per cui alla fine hanno cambiato il nome del prodotto da Tibco JMS a Tibco EMS (Enterprise Messaging Service).

E ho creato sistemi software eterogenei attorno a Tibco EMS.Client C# .NET Winform che interagiscono con il livello intermedio Java/JBoss tramite la messaggistica Tibco EMS.(E dispongono anche di computer integrati industriali WinCE che utilizzano il client Tibco Compact Framework .NET.)

Collegamenti ai miei scritti JMS

Altri suggerimenti

Potrebbe non essere un consiglio di "migliore pratica" qui...ma in base alle esigenze e all'esperienza della vita reale:abbiamo un sistema distribuito, 60 scatole che eseguono ciascuna 10 client eseguono tutte l'attività X e devono prendere l'attività successiva da una coda.La coda viene alimentata da un altro "cliente"...

Avevamo utilizzato la comunicazione tra processi, abbiamo utilizzato MSMQ, abbiamo provato il service broker...Semplicemente non funziona a lungo termine perché stai cedendo il controllo della tua applicazione a Microsoft.Funziona benissimo finché le tue esigenze sono soddisfatte.diventa un inferno quando hai bisogno di qualcosa non supportato.

La soluzione migliore per noi era:Utilizzare una tabella del database SQL come coda.Non reinventare la ruota lì, poiché commetterai errori (serrature).Sono disponibili informazioni su come farlo, è molto semplice e abbiamo gestito oltre 200.000 messaggi ogni 24 ore (con 60x10 = 600 letture e scritture simultanee sulla coda).Questo è in aggiunta allo stesso server SQL che gestisce il resto del materiale dell'applicazione...

Alcuni motivi per cui MSMQ non funziona:

  1. Quando è necessario modificare la logica della coda in non FIFO, ma qualcosa come "il messaggio ROSSO più vecchio" o "il messaggio BLU più vecchio" non è possibile farlo.(So ​​cosa dirà la gente, puoi farlo avendo a coda rossa e un coda blu...Ma cosa succede se il numero/tipo di code è dinamico in base al modo in cui l'applicazione è amministrata e cambia quotidianamente?)

  2. Aggiunge un punto di fallimento e un incubo di distribuzione (la coda è un punto di fallimento e devi occuparti di impostare le giuste autorizzazioni su tutte le caselle per leggere/scrivere messaggi ecc. Nel software Enterprise paghi con il sangue per questo tipo di cose) .Server SQL...tutti i client stanno già scrivendo/leggendo dal DB, è solo un'altra tabella..

Il framework RabbitMQ sembra che qui sia stato trascurato.Se alla gente interessa ancora, ha una base di codice .NET 2.0 e viene fornito con un'associazione WCF simile a netMsmqBinding.L'associazione richiede naturalmente almeno .NET 3.0 e ha più funzionalità rispetto al netMsmqBinding integrato.Oltre a tutto, è Mono friendly.Vale la pena dare un'occhiata.

Che dire di SQL 2005 intermediario di servizi?

Perché non utilizzare ActiveMQ?:)

Se il costo non è un problema (c'è anche uno SKU Express) poi dai un'occhiata al gorilla da 800.000 libbre.WebSphere MQ (serie MQ).Funziona praticamente su qualsiasi piattaforma e supporta così tanti gestori code e modelli di messaggistica diversi che non è appropriato elencarli qui.

Se l'elevata disponibilità è importante, vale la pena dare un'occhiata ad Amazon SQS.Non c'è molto sovraccarico aggiuntivo se i messaggi provengono da posizioni fisiche diverse.Economico e scalabile!

Redis è un'altra razza calda su questa piattaforma.Verificare con l'implementazione dell'accodamento basata su set e anche con il modello Pub/Sub.Sembra promettente

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top