Tibco EMS vs MSMQ contro MQ

Question

Impossibile trovare una risposta su questa domanda, così vorrebbe avviare questo:

Tibco EMS vs. MSMQ vs. MQ.

Come si confrontano queste 3 tecnologie? Quale è migliore e in quali tipi di scenari? In particolare, penso di utilizzare uno di questi in ambiente SOA (.NET + WCF), dove lo scenario maturerà nel tempo.

Ho un ulteriore interesse specifico per la prestazione, che è importante ricordare. Quindi, se viene data una scelta, le prestazioni sono di una priorità critica.

Gradirei avere un tavolo di confronto per un quadro chiaro.

Grazie!

EDIT:

Io sono concentrato su due parametri: le prestazioni e la scalabilità. Scalabilità - come si confrontano queste tecnologie in termini di conteggio degli utenti concorrenti supportati? che può supportare più utenti? lo scenario non ha importanza, scegliamo lo scenario supportato da tutti loro, ad es. code semplici. Prestazioni - esattamente negli stessi scenari, che offre prestazioni più rapide?

Answer 1

Se si desidera utilizzare WCF piuttosto che non di loro è davvero importante. Otterrai la maggior parte di questi solo quando utilizzi la loro API diretta.

MSMQ - tecnologia MS installata con ogni installazione di Windows. È solo la tecnologia di trasporto con supporto per le code.

Tibco EMS - La tecnologia Tibco supporta sia code che argomenti (pubblicazione/sottoscrizione). È costoso e più adatto agli scenari aziendali. Probabilmente avrai bisogno anche di altri strumenti e tecnologie Tibco per implementare una soluzione SOA completa (suite di prodotti Tibco ActiveMatrix). .NET e WCF saranno solo le app collegate a questa infrastruttura che è più progettata per il mondo Java. Funziona su piattaforme non Windows e insieme a Tibco Business Works offre connettori (adattatori) a molte applicazioni LOB. Mi piacciono le API per i prodotti Tibco, ma in realtà non mi piacciono le UI dei loro strumenti.

IBM MQ - La tecnologia IBM supporta le code e in qualche modo emula gli argomenti (pubblica/sottoscrivi). Anche in questo caso è una soluzione commerciale costosa più adatta per gli scenari aziendali in cui sono coinvolti i mainframe - questo è il più grande vantaggio MQ - viene eseguito "ovunque". Ma questa è la fine dei vantaggi. Le API per Java e .NET sono terribili. L'API .NET è piena di bug e non funziona come previsto. IBM non capisce librerie .NET controllo delle versioni, che porta a problemi terribili quando si sposta l'applicazione client per macchine con diversi clienti MQ installati, ecc

Edit:

Ci sono stati diversi domanda/commenti su ciò che i problemi MQ ha? Come pochi esempi è possibile controllare my MQ questions. Non tutte le domande sono in realtà un problema, ma ne troverai alcune che puntano direttamente ai bug. Questi problemi possono già essere risolti nelle nuove versioni dei client MQ ma ciò non significa che non ci siano altri. Generalmente ho trovato MQ .NET API la libreria più frustrante che abbia mai usato - ha persino battuto SharePoint odiato.

D'altra parte, se hai solo bisogno di inviare e ricevere messaggi e non hai intenzione di fare qualcosa di speciale o di usare funzioni di basso livello, dovresti essere OK. Alla fine l'API viene utilizzata per un po 'e i casi di utilizzo comune dovrebbero funzionare - se non sei abbastanza contento di colpire i bug di regressione.

Answer 2

Anche in questo caso è costoso soluzione commerciale più adatto per gli scenari aziendali in cui sono coinvolti i mainframe

Non certo perché lei ha citato mainframe. Molti clienti aziendali MQ non li hanno.

IBM MQ - tecnologia IBM di supporto code ed è anche in qualche modo emula argomenti (pubblicazione/sottoscrizione)

MQ v7.0.0 (pubblicato 2008) e poi supporta argomenti pub/sub come caratteristica nativa , non è coinvolta l'emulazione.

Le API per Java e .NET sono terribili.

Le classi MQ per Java e JMS si sono evolute in oltre 10 anni e sono utilizzate pesantemente da migliaia di imprese.

L'API .NET è piena di bug e non funziona come previsto.

L'API .Net è in circolazione da 7+ anni in alcune importanti versioni di MQ. Immagino che gli errori ovvi sarebbero stati scossi a quest'ora.

Sono concentrato su due parametri: prestazioni e scalabilità.

MQ ha scalabilità illimitata. Le prestazioni sono ottime anche senza sintonizzazione.

Answer 3

MQ è la soluzione migliore solo se è necessario integrarsi con molti mainframe. Pub/Sub è implementato male e le molte API sono "strane da usare".

Se tutte le applicazioni sono Windows, MSMQ potrebbe essere una buona scelta, ma sarà difficile collegarsi ai mondi Unix o Java.

L'intera comunità Java standardizzata su JMS, così TIBCO EMS è una buona scelta se si desidera connettere applicazioni non Windows.

Answer 4

Per uno scenario di integrazione semplice, ovvero 2 applicazioni che interagiscono in modo Point to Point, nessuna differenza sarà presente. Faresti meglio a controllare il supporto di ciascuna tecnologia all'interno delle tue applicazioni. E in questo tipo di scenari, non dovresti preoccuparti delle prestazioni poiché il tempo di messaggistica non dovrebbe essere il problema principale. D'altra parte, la selezione reale si baserebbe sul modello target per l'integrazione dell'intera azienda. Ad esempio, - Stai facendo qualsiasi funzione di mediazione, ad esempio trasformazione dei dati, mappatura dei protocolli, ecc. - Integrerai i sistemi in un modo point-to-point o potresti considerare di avere un hub/ESB? - Tratterai gli aspetti di sicurezza nel tuo scenario di integrazione (Autorizzazione, autenticazione, auditing, crittografia, scambio di certificati ...ecc.) Infine, avere una visione del genere ti permetterà di capire meglio quali sono i reali vincoli che hai per il tuo design. Personalmente, opterei per WCF solo se non mi aspetto scenari di integrazione complessi e non sono disposto a spendere soldi per la soluzione. E vorrei andare per IBM se sto costruendo una fondazione per SOA. E andrò su Tibco se sto pianificando un'integrazione basata su Java con un ambito definito.