Procedure consigliate per comunicazioni in coda

In questo argomento vengono illustrate le procedure consigliate per le comunicazioni in coda in Windows Communication Foundation (WCF). Nelle sezioni seguenti vengono descritte le procedure consigliate in funzione dello scenario.

Messaggistica in coda di tipo veloce ed efficiente

Per scenari che richiedono la separazione fornita dalla messaggistica in coda nonché velocità, elevate prestazioni ed efficienza, utilizzare una coda non transazionale e impostare la proprietà ExactlyOnce su false.

È inoltre possibile scegliere di non incorrere nell'onere delle scritture su disco impostando la proprietà Durable su false.

La protezione ha implicazioni sulle prestazioni. Per ulteriori informazioni, vedere Considerazioni sulle prestazioni.

Messaggistica in coda end-to-end affidabile

Nelle sezioni seguenti vengono descritte le procedure consigliate per scenari che richiedono messaggistica affidabile end-to-end.

Trasferimento affidabile di base

Per l'affidabilità end-to-end, impostare la proprietà ExactlyOnce su true per garantire il trasferimento. La proprietà Durable può essere impostata su true o false a seconda delle necessità (l'impostazione predefinita è true). La proprietà Durable è generalmente impostata su true come parte dell'affidabilità end-to-end. Ciò implica un costo in termini di prestazioni, ma rende durevole il messaggio. In questo modo il messaggio non andrà perso se il gestore delle code si arresta in modo anomalo.

Utilizzo delle transazioni

È necessario utilizzare transazioni per garantire l'affidabilità end-to-end. Le garanzie ExactlyOnce assicurano solo che i messaggi vengano recapitati alla coda di destinazione. Per garantire che il messaggio venga ricevuto, utilizzare le transazioni. Se il servizio si arresta in modo anomalo e se si opera senza transazioni, è possibile che si verifichi la perdita del messaggio che sta per essere recapitato, ma che appare come effettivamente recapitato.

Utilizzo delle code dei messaggi non recapitabili

Le code dei messaggi non recapitabili assicurano la ricezione di una notifica se un messaggio non viene recapitato alla coda di destinazione. È possibile utilizzare la coda dei messaggi non recapitabili fornita dal sistema o una personalizzata. È generalmente consigliato l'utilizzo di una coda dei messaggi non recapitabili personalizzata poiché consente di inviare messaggi non recapitabili da una singola applicazione a un'unica coda dei messaggi non recapitabili. In caso contrario, tutti i messaggi non recapitabili che si verificano per tutte le applicazioni in esecuzione nel sistema vengono recapitati a un'unica coda. Ogni applicazione deve quindi cercare nella coda dei messaggi non recapitabili per trovare quelli pertinenti per quell'applicazione. L'utilizzo di una coda dei messaggi non recapitabili personalizzata a volte non è possibile, ad esempio quando si utilizza MSMQ 3.0.

La disattivazione delle code dei messaggi non recapitabili per la comunicazione affidabile end-to-end non è consigliata.

Per ulteriori informazioni, vedere Utilizzo di code di messaggi non recapitabili per gestire errori di trasferimento dei messaggi.

Utilizzo della gestione dei messaggi non elaborabili

La gestione dei messaggi non elaborabili consente il ripristino dopo un errore per proseguire l'elaborazione dei messaggi.

Quando si utilizza la funzionalità di gestione dei messaggi non elaborabili, verificare che la proprietà ReceiveErrorHandling sia impostata sul valore appropriato. L'impostazione della proprietà su Drop significa che i dati vanno persi. L'impostazione della proprietà su Fault genera invece errori nell'host del servizio quando viene rilevato un messaggio non elaborabile. Se si utilizza MSMQ 3.0, Fault è l'opzione migliore per evitare perdite di dati e per spostare il messaggio non elaborabile. Se si utilizza MSMQ 4.0, Move è l'opzione consigliata. Move sposta un messaggio non elaborabile fuori dalla coda consentendo al servizio di proseguire nell'elaborazione di nuovi messaggi. Il servizio dei messaggi non elaborabili è in grado quindi di elaborare separatamente il messaggio non elaborabile.

Per ulteriori informazioni, vedere Gestione dei messaggi non elaborabili.

Raggiungimento di velocità effettive elevate

Per raggiungere velocità effettive elevate in un singolo endpoint, utilizzare gli elementi seguenti:

• Batch transazionale. Il batch transazionale garantisce la lettura di molti messaggi in una singola transazione. In tal modo vengono ottimizzati i commit della transazione, aumentando le prestazioni complessive. Lo svantaggio del batch consiste nel fatto che se si verifica un errore in un singolo messaggio all'interno di un batch, verrà eseguito il rollback dell'intero batch e i messaggi dovranno essere elaborati uno alla volta fino a che il batch non sarà nuovamente sicuro. Nella maggior parte dei casi i messaggi non elaborabili sono rari, pertanto il batch è il modo preferito per aumentare le prestazioni del sistema, in particolare quando vi sono altri gestori delle risorse che partecipano alla transazione. Per ulteriori informazioni, vedere Raggruppamento di messaggi in una transazione.
• Concorrenza. La concorrenza aumenta la velocità effettiva, ma può anche provocare conflitti nelle risorse condivise. Per ulteriori informazioni, vedere Concurrency.
• Limitazione. Per ottenere prestazioni ottimali, limitare il numero di messaggi nella pipeline del dispatcher. Per un esempio di come realizzare una limitazione, vedere Throttling.

Quando si utilizza il batch, è necessario sapere che la concorrenza e la limitazione danno luogo a batch simultanei.

Per raggiungere velocità effettive e disponibilità più elevate, utilizzare una farm di servizi WCF in grado di leggere dalla coda. In questo caso, tutti i servizi interessati devono esporre lo stesso contratto nello stesso endpoint. L'approccio della farm funziona in modo ottimale per applicazioni che hanno elevate frequenze di produzione di messaggi poiché consente a un certo numero di servizi di leggere dalla stessa coda.

Quando si utilizzano le farm, è necessario sapere che le letture transazionali remote non sono supportate in MSMQ 3.0. MSMQ 4.0 supporta le letture transazionali remote.

Per ulteriori informazioni, vedere Raggruppamento di messaggi in una transazione e Differenze nelle funzionalità di accodamento in Windows Vista, Windows Server 2003 e Windows XP.

Accodamento con unità di semantica del lavoro

In alcuni scenari i messaggi raggruppati in una coda possono essere correlati insieme e, pertanto, il loro ordine è significativo. In tali scenari, viene elaborato un gruppo di messaggi correlati come singola unità. Ciò significa che tutti i messaggi vengono elaborati correttamente oppure che nessun di essi viene elaborato. Per implementare tale comportamento, utilizzare sessioni con code.

Per ulteriori informazioni, vedere Raggruppamento di messaggi in coda in una sessione.

Correlazione di messaggi request/reply

Sebbene le code siano tipicamente unidirezionali, in alcuni scenari è necessario determinare una correlazione tra una risposta ricevuta a una richiesta inviata precedentemente. Se tale correlazione viene richiesta, è consigliato applicare al messaggio la propria intestazione del messaggio SOAP contenente informazioni sulla correlazione. In genere, il mittente allega questa intestazione al messaggio e il destinatario, dopo aver elaborato il messaggio e aver risposto con un messaggio nuovo in una coda di risposte, allega l'intestazione del messaggio del mittente contenente le informazioni sulla correlazione così che il mittente possa identificare il messaggio di risposta con il messaggio di richiesta.

Integrazione con applicazioni non WCF

Utilizzare MsmqIntegrationBinding in caso di integrazione di servizi WCF o di client con servizi o client non WCF. L'applicazione non WCF può essere un'applicazione MSMQ scritta utilizzando System.Messaging, COM+, Visual Basic o C++.

Quando si utilizza MsmqIntegrationBinding, è necessario sapere che:

• Il corpo di un messaggio WCF non equivale al corpo di un messaggio MSMQ. Quando si invia un messaggio WCF utilizzando un'associazione in coda, il corpo del messaggio WCF è posizionato all'interno di un messaggio MSMQ. L'infrastruttura MSMQ vede solo il messaggio MSMQ ignorando queste informazioni aggiuntive.
• MsmqIntegrationBinding supporta i tipi di serializzazione più comuni. In base al tipo di serializzazione, il tipo del corpo del messaggio generico, MsmqMessage, prende parametri di tipo diverso. ByteArray, ad esempio, richiede MsmqMessage<byte[]> e Stream richiede MsmqMessage<Stream>.
• Con la serializzazione XML, è possibile specificare il tipo conosciuto utilizzando l'attributo KnownTypes nell'elemento <behavior> of <serviceBehaviors> che viene quindi utilizzato per determinare come deserializzare il messaggio XML.

Vedere anche

Attività

Procedura: scambiare messaggi in coda con endpoint WCF
Procedura: scambiare messaggi con endpoint WCF e con applicazioni del sistema di accodamento dei messaggi

Concetti

Accodamento in WCF
Raggruppamento di messaggi in coda in una sessione
Raggruppamento di messaggi in una transazione
Utilizzo di code di messaggi non recapitabili per gestire errori di trasferimento dei messaggi
Gestione dei messaggi non elaborabili
Differenze nelle funzionalità di accodamento in Windows Vista, Windows Server 2003 e Windows XP
Protezione dei messaggi mediante protezione del trasporto
Protezione dei messaggi mediante protezione a livello di messaggio
Risoluzione dei problemi relativi ai messaggi in coda