Buona strategia per l'accodamento dei messaggi?

Question

Attualmente sto progettando un'applicazione che alla fine voglio spostare su Windows Azure. A breve termine, tuttavia, verrà eseguito su un server che ospiterò io stesso.

L'applicazione include un numero di applicazioni Web separate: alcuni di questi sono essenzialmente servizi WCF che ricevono dati e alcuni sono siti per consentire agli utenti di gestire i dati. Inoltre, sarà necessario un servizio di lavoro in esecuzione in background che elaborerà i dati in vari modi.

Sono molto entusiasta di utilizzare un'architettura disaccoppiata per questo. Idealmente, voglio che i componenti (ad esempio le app Web e il servizio di lavoro) sappiano il meno possibile l'uno sull'altro. Sembra che l'uso di una coda di messaggi sia la soluzione migliore qui: le app Web possono accodare messaggi con le unità di lavoro nella coda e il servizio di lavoro può individuarli e elaborarli secondo necessità.

Tuttavia, desidero elaborare un buon set di tecnologie per fare ciò, tenendo presente che alla fine mi sposterò ad Azure e voglio ridurre al minimo la quantità di rilavorazione che dovrò fare quando migrare al cloud. Azure ha un componente Queue in cui è ideale per le mie esigenze. Quello che mi piacerebbe fare è creare qualcosa da me stesso che lo riproduca il più fedelmente possibile.

Sembra che ci sono diverse opzioni (sto usando .NET su Windows, con una fine del 2005 di nuovo SQL Server) - quelli che ho trovato finora sono:

• MSMQ
• SQL Server service Broker
• rotazione mia utilizzando una tabella di database e alcune stored procedure

mi chiedevo se qualcuno ha qualche suggerimento per questo - o se qualcuno ha fatto qualcosa di simile e ha consigli sulle cose da fare/evitare. Mi rendo conto che ogni situazione è diversa, ma in questo caso penso che i miei requisiti di accodamento siano piuttosto generici, quindi mi piacerebbe sentire le opinioni di qualcun altro sul modo migliore per farlo.

Grazie in anticipo,

John

Answer 1

Se hai Azure in mente, forse si dovrebbe iniziare a dritto su Azure come le API e semnatics sono significativamente diverse tra code Azure e qualsiasi MSMQ o SSB.

Un rapido confronto 3048 metri di MSMQ contro SSB (lascio una consuetudine tavolo-come-coda di confronto in quanto dipende davvero come si implementa esso ...)

• Deployment : MSMQ è un componente di Windows, SSB è un componente SQL. SSB richiede un'istanza SQL per archiviare qualsiasi messaggio, quindi i client disconnessi devono accedere a un'istanza (può essere espressa). MSMQ richiede la distribuzione di MSMQ sul client (parte del sistema operativo, ma installazione facoltativa).
• Programmabilità: MSMQ offre un canale WCF completo e supportato. SSB offre solo un canale WCF sperimentale a http://ssbwcf.codeplex.com
• Prestazioni: SSB sarà significativamente più veloce di MSMQ in modalità transazionale.MSMQ sarà più veloce se operiamo in modalità non trasferita (best effort, non ordinato, consegna)
• Queriability: le code SSB possono essere uppon SELEZIONATE (visualizzare qualsiasi messaggio, SQL completo JOIN/WHERE/ORDER/GROUP power), Le code MSMQ possono essere sbirciate (solo il prossimo messaggio)
• Recuperabilità: le code SSB sono integrate nel database in modo da essere sottoposte a backup e ripristinate con il database, mantenendo uno stato coerente con lo stato dell'applicazione. Le code MSMQ vengono sottoposte a backup nel sottosistema di backup dei file NT, pertanto per mantenere il backup sincronizzato (coerente) la coda dei database e deve essere sospesa.
• Transactions (dal momento che ogni enqueue/dequeue è sempre accompagnato da un aggiornamento del database): SSB è completamente integrato in SQL così dequeueing e enqueueing sono operazioni di transazione locali. MSMQ è una TM separata (Transaction Manager), pertanto la coda/coda deve essere un'operazione di transazione distribuita per registrare SQL e MSMQ nella transazione.
• Gestione e monitoraggio: entrambi uguali male. Nessun attrezzo qualunque.
• Messaggi correlati Elaborazione dei messaggi: SSB può bloccare l'elaborazione del messaggio correlato da thread concurent tramite Conversation Group Locking integrato.
• Event Driven: SSB ha Activation per avviare stored procedure, MSMQ utilizza il servizio Windows Activation. Simile. SSB ha tuttavia capacità di bilanciamento del carico automatico a causa del modo in cui WAITFOR (RECEIVE) e MAX_QUEUE_READERS interagiscono.
• Disponibilità: SSB piggyback nella cronologia High Availability di SQL Server, può funzionare in un ambiente di miraggio in cluster o in database. MSMQ cavalca solo la storia del cluster di Windows. Il mirroring del database è molto più economico del clustering come soluzione HA.

Inoltre mi piacerebbe aggiungere che SSB e MSMQ differiscono in modo significativo a livello diLa primitivo offrono: SSB primitiva è un conversazione, mentre MSMQ primitiva è un messaggio. Pensa alla semantica TCP vs UDP.

Answer 2

Scegli un back-end di coda che funzioni per te o che sia più adatto al tuo ambiente. @Remus ha fornito un ottimo confronto tra MSMQ e SSB. MSMQ sarà il più facile da implementare, ma presenta alcuni limiti notevoli, mentre SSB si sentirà molto pesante come all'altro estremo dello spettro.

avere il vostro modo
Per ridurre al minimo la rielaborazione da voi applicazioni, astratte le code accedono dietro un'interfaccia, e quindi fornire un'implementazione per il trasporto di coda che in ultima analisi decide di andare con. Quando è il momento di spostarsi su Azure o su un altro trasporto in coda, è sufficiente fornire una nuova implementazione dell'interfaccia.

È possibile controllare la semantica di come si desidera interagire con la coda per fornire un'API coerente utilizzabile dalle applicazioni.

una vaga idea potrebbe essere:

interface IQueuedTransport 
{ 
    void SendMessage(XmlDocument); 
    XmlDocument ReceiveMessage(); 
} 

public class MSMQTransport : IQueuedTransport {} 
public class AzureQueueTransport : IQueuedTransport {} 

Potrebbe non essere la costruzione l'essere-tutti i trasporti in coda, proprio quello che soddisfa le vostre esigenze. Se lavori con Xml, passa xml. Se lavori su matrici di byte, passa le matrici di byte.:)

Buona fortuna!
Z

Answer 3

Utilizzare Win32 Mailslots. Saranno affidabili su un singolo server, sono facili da implementare e non richiedono alcun software aggiuntivo.