Quali sono i vantaggi dell'utilizzo di WCF rispetto a framework come MassTransit o client MSMQ scritto a mano?

Question

Sto cercando di utilizzare MSMQ come soluzione per eseguire un'esecuzione asincrona nel mio prossimo progetto. Voglio conoscere le differenze tra l'utilizzo di WCF e framework come MassTransit o persino client MSMQ scritti a mano per posizionare / leggere attività su MSMQ.

Fondamentalmente l'applicazione sarà costituita da diversi siti Web (interni tramite LAN o esterni tramite Internet) che leggono / scrivono dati attraverso un livello di servizio (sia esso WCF o normale servizio web). Quindi questo livello di servizio farà una delle due cose seguenti: 1. scrivere i dati nel database 2. e / o attivare il processo in background inserendo un messaggio nella coda. 3. ovviamente può anche recuperare i dati dal database. Il piccolo agente (un servizio Windows) sull'altro lato della coda monitorerà la coda ed eseguirà in base al comando dell'attività.

Questa architettura sarà abbastanza facile da ridimensionare (aggiungere più code e agenti) e facile da implementare rispetto a RPC o esecuzione distribuita o altro. E l'elaborazione degli agenti non deve essere in tempo reale. L'agente e il livello di servizio sono applicazioni separate, tranne per il fatto che condividono gli oggetti di dominio comuni, i repository ecc.

Cosa ne pensi? Suggerimenti di architettura per i requisiti di cui sopra sono i benvenuti. Grazie!

Answer 1

WCF aggiunge un'astrazione su MSMQ. Infatti, una volta definiti i contratti compatibili (le operazioni devono essere OneWay), è possibile cambiare MSMQ nella configurazione, in modo trasparente. (Ad esempio, potresti passare al normale HttpWS o a un binding NetTcp.)

Dovresti valutare gli altri vantaggi WCF, come la sicurezza e così via, per vedere come si adattano alle tue esigenze. Ancora una volta, dovrebbero essere ragionevolmente trasparenti dal fatto che stai usando MSMQ sotto. Ad esempio, l'aggiunta di sicurezza SOAP e così via dovrebbe "funzionare", indipendentemente dall'uso di MSMQ.

(Sebbene, IIRC, è comunque necessario accedere al desktop su ogni macchina che utilizza MSMQ, con l'account del servizio che utilizzerà MSMQ , per generare il certificato nel profilo locale delle macchine. quindi, non funziona molto bene da IIS6, poiché i profili utente non sono caricati. Una vera seccatura in generale, ma nulla a che fare con WCF in particolare.)

---

A parte questo:

Hai guardato il Service Broker di SQL Server? Dopo aver usato MSMQ + WCF e SSSB, penso che SSSB sia ampiamente più facile da configurare e gestire. SSSB funziona con i comandi T-SQL su qualsiasi client SQL (lo uso da Mono, su Linux, con transazioni). Ti darà anche invio / ricezione transazionale, anche da remoto (penso che MSMQ 4 ora lo consenta). Prende davvero molto del dolore dall'accodamento dei messaggi e se stai già utilizzando SQL Server ...

SSSB è spesso trascurato poiché SQL Management Studio non ha progettisti di GUI per tutto, ma non è difficile ed è un'ottima opzione. L'unico aspetto negativo è che se si desidera la funzionalità di invio locale (ovvero, messaggio di coda quando la rete è inattiva), è necessario eseguire un'istanza locale di SQL Express.

Answer 2

La tua architettura sembra solida e ragionevole. Tuttavia, è necessario considerare l'utilizzo del trasporto MSMQ netto WCF su classi MSMQ codificate manualmente. WCF racchiude questa funzionalità comune in un bel modello di programmazione. Inoltre credo che ci siano alcuni miglioramenti nel protocollo usato da Wcf rispetto al System.Messaging di base

Answer 3

Dai un'occhiata al valore aggiunto su MSMQ semplice:

http://readthedocs.org/docs/masstransit/en/ ultima / panoramica / valueadd.html

In breve, si ottengono molti concetti di messaggistica chiaramente presentati nell'API con MassTransit; in una misura che non avresti se lo avessi codificato a mano o utilizzato WCF.