Endpoint di servizio e indirizzamento delle code

Questo argomento illustra il modo in cui i client indirizzano i servizi che leggono dalle code e come gli endpoint di servizio si mappano alle code. Come promemoria, la figura seguente mostra la distribuzione classica dell'applicazione WCF in coda di Windows Communication Foundation.

Affinché il client invii il messaggio al servizio, il client indirizza il messaggio alla coda di destinazione. Per consentire al servizio di leggere i messaggi dalla coda, imposta il suo indirizzo di ascolto verso la coda di destinazione. L'indirizzamento in WCF è basato su URI (Uniform Resource Identifier) mentre i nomi delle code di accodamento messaggi (MSMQ) non sono basati su URI. È quindi essenziale comprendere come gestire le code create in MSMQ tramite WCF.

Indirizzamento MSMQ

MSMQ usa percorsi e nomi di formato per identificare una coda. I percorsi specificano un nome host e un oggetto QueueName. Facoltativamente, può esistere un elemento Private$ tra il nome host e l'elemento QueueName per indicare una coda privata non pubblicata nel servizio directory di Active Directory.

I nomi dei percorsi vengono mappati a "FormatNames" per determinare altri aspetti dell'indirizzo, compresi l'indirizzamento e il protocollo di trasferimento del gestore delle code. Queue Manager gestisce due protocolli di trasferimento: il protocollo MSMQ nativo e il protocollo SRMP (SOAP Reliable Messaging Protocol).

Per ulteriori informazioni sui nomi di formato e percorso MSMQ, consultare About Message Queuing.

NetMsmqBinding e indirizzamento del servizio

Quando si indirizza un messaggio a un servizio, lo schema nell'URI viene scelto in base al trasporto utilizzato per la comunicazione. Ogni trasporto in WCF ha uno schema univoco. Lo schema deve riflettere la natura del trasporto utilizzato per la comunicazione. Ad esempio, net.tcp, net.pipe, HTTP e così via.

Il trasporto in coda MSMQ in WCF espone uno schema net.msmq. Qualsiasi messaggio indirizzato usando lo schema net.msmq viene inviato tramite il NetMsmqBinding canale di trasporto in coda MSMQ.

L'indirizzamento di una coda in WCF si basa sul modello seguente:

net.msmq: // <host-name> / [private/] <queue-name>

dove:

• < host-name> è il nome del computer che ospita la Target Queue.

• [private] è facoltativo. Viene usato quando si punta a una coda di destinazione che è una coda privata. Per gestire una coda pubblica, non è necessario specificare privato. Si noti che, a differenza dei percorsi MSMQ, non esiste alcun valore "$" nel formato URI WCF.

• < queue-name> è il nome della coda. Il nome della coda può anche fare riferimento a una coda secondaria. Pertanto, <queue-name> = <name-of-queue>[;sub-queue-name].

Esempio1: per gestire una coda privata PurchaseOrders ospitata nel computer abc atadatum.com, l'URI sarà net.msmq://abc.adatum.com/private/PurchaseOrders.

Esempio 2: per gestire una coda pubblica AccountsPayable ospitato nel computer def atadatum.com, l'URI sarà net.msmq://def.adatum.com/AccountsPayable.

L'indirizzo della coda viene usato come URI di ascolto da parte del listener per leggere i messaggi. In altre parole, l'indirizzo della coda è equivalente alla porta di ascolto del socket TCP.

Un endpoint che legge da una coda deve specificare l'indirizzo della coda usando lo stesso schema specificato in precedenza durante l'apertura di ServiceHost. Per esempi, vedere Net MSMQ Binding.

Molti contratti in coda

I messaggi in una coda possono implementare contratti diversi. In questo caso, è essenziale che uno dei seguenti sia vero per leggere ed elaborare correttamente tutti i messaggi:

• Specificare un endpoint per un servizio che implementa tutti i contratti. Questo è l'approccio consigliato.

• Specificare più endpoint con contratti diversi, ma assicurarsi che tutti gli endpoint usino lo stesso NetMsmqBinding oggetto. La logica di distribuzione in ServiceModel utilizza una pompa di messaggi che legge i messaggi dal canale di trasporto per la distribuzione, demultiplexando i messaggi in base al contratto verso endpoint diversi. Viene creato un message pump per una coppia di URI/binding di ascolto. L'indirizzo della coda viene usato come URI di ascolto dal listener in coda. Se tutti gli endpoint usano lo stesso oggetto di associazione, si garantisce che un unico pump di messaggio venga usato per leggere il messaggio e demultiplexare verso gli endpoint pertinenti in base al contratto.

Messaggistica SRMP

Come illustrato in precedenza, è possibile usare il protocollo SRMP per i trasferimenti da coda a coda. Questo viene comunemente usato quando un trasporto HTTP trasmette messaggi tra la coda di trasmissione e la coda di destinazione.

Per usare il protocollo di trasferimento SRMP, indirizzare i messaggi usando lo schema URI net.msmq, come indicato in precedenza, e specificare la scelta di SRMP o SRMP protetto nella QueueTransferProtocol proprietà di NetMsmqBinding.

Specificare la QueueTransferProtocol proprietà è una funzionalità solo di invio. Si tratta di un'indicazione del cliente quale tipo di protocollo di trasferimento della coda utilizzare.

Uso di Active Directory

MSMQ include il supporto per l'integrazione di Active Directory. Quando MSMQ è installato con l'integrazione di Active Directory, il computer deve far parte di un dominio Windows. Active Directory è utilizzato per pubblicare le code per l'individuazione, e tali code sono chiamate code pubbliche. Quando si gestisce una coda, la coda può essere gestita tramite Active Directory. Questo è simile al modo in cui viene usato Domain Name System (DNS) per risolvere l'indirizzo IP di un nome di rete. La UseActiveDirectory proprietà in NetMsmqBinding è un valore booleano che indica se il canale in coda deve usare Active Directory per risolvere l'URI della coda. Per impostazione predefinita, è impostato su false. Se la UseActiveDirectory proprietà è impostata su true, il canale in coda usa Active Directory per convertire l'URI net.msmq:// in nome di formato.

La UseActiveDirectory proprietà è significativa solo per il client che invia il messaggio perché viene usato per risolvere l'indirizzo della coda durante l'invio di messaggi.

Mappatura dell'URI net.msmq ai nomi di formato dei messaggi di accodamento

Il canale in coda gestisce la conversione del nome URI net.msmq fornito al canale nei nomi di formato MSMQ. Nella tabella seguente vengono riepilogate le regole usate per eseguire il mapping tra di esse.

Indirizzo della coda WCF basata su URI	Utilizzare la proprietà Active Directory	Proprietà Queue Transfer Protocol	Nomi di formato MSMQ risultanti
Net.msmq://<machine-name>/private/abc	False (impostazione predefinita)	Nativo (impostazione predefinita)	DIRECT=OS:machine-name\private$\abc
Net.msmq://<machine-name>/private/abc	Falso	SRMP	DIRECT=http://machine/msmq/private$/abc
Net.msmq://<machine-name>/private/abc	Vero	Nativa	PUBLIC=some-guid (GUID della coda)

Lettura di messaggi dalla coda Dead-Letter o dalla coda Poison-Message

Per leggere i messaggi da una coda di messaggi velenosi che è una subcoda della coda di destinazione, apri ServiceHost con l'indirizzo della subcoda.

Esempio: Un servizio che legge dalla coda di messaggi avvelenati della coda privata PurchaseOrders dal computer locale verrebbe indirizzato a net.msmq://localhost/private/PurchaseOrders; avvelenati.

Per leggere i messaggi da una coda di messaggi non recapitabili transazionali di sistema, l'URI deve essere nel formato net.msmq://localhost/system$; DeadXact.

Per leggere i messaggi da una coda di messaggi non recapitabili non transazionali di sistema, l'URI deve essere nel formato net.msmq://localhost/system$;DeadLetter.

Quando si usa una coda di messaggi non recapitabili personalizzata, si noti che la coda dei messaggi non recapitabili deve risiedere nel computer locale. Di conseguenza, l'URI per la coda di messaggi non recapitabili è limitato alla forma:

net.msmq: //localhost/ [private/] <custom-dead-letter-queue-name>.

Un servizio WCF verifica che tutti i messaggi ricevuti siano stati indirizzati alla coda specifica su cui è in ascolto. Se la coda di destinazione del messaggio non corrisponde alla coda in cui si trova, il servizio non elabora il messaggio. Si tratta di un problema che i servizi in ascolto di una coda di messaggi non recapitabili devono risolvere perché qualsiasi messaggio nella coda dei messaggi non recapitabili doveva essere recapitato altrove. Per leggere i messaggi da una coda di messaggi non recapitabili o da una coda di messaggi veleni, è necessario usare un ServiceBehavior con il parametro Any. Per un esempio, consultare Code di messaggi non recapitabili.

MsmqIntegrationBinding e indirizzamento dei servizi

Il MsmqIntegrationBinding è usato per la comunicazione con le applicazioni MSMQ tradizionali. Per semplificare l'interoperabilità con un'applicazione MSMQ esistente, WCF supporta solo l'indirizzamento dei nomi di formato. Pertanto, i messaggi inviati con questa associazione devono essere conformi allo schema URI:

msmq.formatname:<MSMQ-format-name>>

Il nome-formato MSMQ è nella forma specificata da MSMQ in Informazioni su Accodamento dei messaggi.

Si noti che è possibile usare solo nomi di formato diretto e nomi di formato pubblico e privato (richiede l'integrazione di Active Directory) quando si ricevono messaggi da una coda usando MsmqIntegrationBinding. È tuttavia consigliabile usare nomi di formato diretto. Ad esempio, in Windows Vista, l'uso di qualsiasi altro nome di formato causa un errore perché il sistema tenta di aprire una coda secondaria, che può essere aperta solo con nomi di formato diretto.

Quando si indirizza SRMP tramite MsmqIntegrationBinding, non è necessario aggiungere /msmq/ nel nome del formato diretto per facilitare l'invio di Internet Information Services (IIS). Ad esempio: quando si indirizza una coda abc usando il protocollo SRMP, anziché DIRECT=http://adatum.com/msmq/private$/abc, dovresti usare DIRECT=http://adatum.com/private$/abc.

Si noti che non è possibile usare l'indirizzamento net.msmq:// con MsmqIntegrationBinding. Poiché MsmqIntegrationBinding supporta l'indirizzamento dei nomi di formato MSMQ in formato libero, è possibile usare un servizio WCF che usa questa associazione per usare le funzionalità multicast e lista di distribuzione in MSMQ. Un'eccezione è specificare CustomDeadLetterQueue quando si utilizza il MsmqIntegrationBinding. Deve essere nel formato net.msmq://, in modo analogo a come viene specificato usando .NetMsmqBinding

Vedere anche

• Hosting web di un'applicazione in attesa