Accesso ai servizi tramite client
Le applicazioni client devono creare, configurare e utilizzare oggetti client o canale WCF per comunicare con i servizi. Nell'argomento Panoramica dei client WCF viene fornita una panoramica degli oggetti e dei passaggi coinvolti nella creazione e nell'utilizzo di oggetti client e canale.
In questo argomento vengono fornite informazioni dettagliate su alcuni dei problemi relativi ad applicazioni client e oggetti client e canale, che possono essere utili a seconda dello scenario.
Panoramica
In questo argomento vengono descritti il comportamento e i problemi relativi a:
- Durata di canali e sessioni.
- Gestione delle eccezioni.
- Problemi che causano blocchi.
- Inizializzazione interattiva dei canali.
Durata di canali e sessioni
Le applicazioni Windows Communication Foundation (WCF) includono due categorie di canali, ovvero i canali di datagramma e quelli con sessione.
Si definisce di datagramma un canale in cui tutti i messaggi non sono correlati. Con un canale di datagramma, l'eventuale esito negativo di un'operazione di input o di output non ha di norma alcun effetto sulla successiva operazione ed è possibile riutilizzare lo stesso canale. Ne consegue che i canali di datagramma non hanno in genere esito negativo.
I canali con sessione sono invece canali con una connessione all'altro endpoint. I messaggi in una sessione su uno dei lati vengono sempre correlati alla stessa sessione sull'altro lato. Inoltre, perché una sessione possa essere considerata riuscita, entrambi i partecipanti a essa devono concordare sul fatto che i requisiti della conversazione siano stati soddisfatti. In caso contrario, il canale con sessione può avere esito negativo.
Aprire i client in modo esplicito o implicito chiamando la prima operazione.
Nota
Tentare di rilevare esplicitamente i canali con sessione in errore non è in genere utile, poiché il momento in cui si riceve la notifica dipende dall'implementazione della sessione. Poiché, ad esempio, la classe System.ServiceModel.NetTcpBinding (con la sessione affidabile disattivata) fa emergere la sessione della connessione TCP, se si è in ascolto dell'evento System.ServiceModel.ICommunicationObject.Faulted sul servizio o sul client, è probabile che si riceva una notifica immediata in caso di errore di rete. Le sessioni affidabili (stabilite da associazioni in cui la classe System.ServiceModel.Channels.ReliableSessionBindingElement è attivata) sono però progettate per isolare i servizi da piccoli errori di rete. Se la sessione può essere ristabilita entro un periodo di tempo ragionevole, la stessa associazione, configurata per sessioni affidabili, potrebbe non generare errori fino a quando l'interruzione non dura per un periodo di tempo più lungo.
La maggior parte delle associazioni fornite dal sistema (che espongono canali al livello di applicazione) utilizza sessioni per impostazione predefinita, diversamente dall'associazione System.ServiceModel.BasicHttpBinding. Per ulteriori informazioni, vedere Utilizzo di sessioni.
Utilizzo corretto delle sessioni
Le sessioni offrono un modo per sapere se l'intero scambio di messaggi è completo e se entrambi i lati lo considerano riuscito. È consigliabile che un'applicazione chiamante apra il canale, lo utilizzi e lo chiuda all'interno di un unico blocco try. Se un canale di sessione è aperto, il metodo System.ServiceModel.ICommunicationObject.Close viene chiamato una volta e la chiamata viene restituita correttamente, la sessione ha esito positivo. Per esito positivo si intende, in questo caso, che tutto il recapito garantisce che l'associazione specificata è stata soddisfatta e che l'altro lato non ha chiamato System.ServiceModel.ICommunicationObject.Abort sul canale prima di chiamare Close.
Nella sezione seguente viene fornito un esempio di tale approccio client.
Gestione delle eccezioni
La gestione di eccezioni nelle applicazioni client è semplice. Se un canale viene aperto, utilizzato e chiuso all'interno di un blocco try, la conversazione ha avuto esito positivo, a meno che non venga generata un'eccezione. In genere, se viene generata un'eccezione, la conversazione viene interrotta.
Nota
Non è consigliabile utilizzare l'istruzione using (Using in Visual Basic), poiché la fine dell'istruzione using può causare eccezioni che possono mascherare altre eccezioni che potrebbe essere necessario conoscere. Per ulteriori informazioni, vedere Avoiding Problems with the Using Statement.
Nell'esempio di codice seguente viene illustrato il modello client consigliato utilizzando un blocco try/catch e non l'istruzione using.
Nota
La verifica del valore della proprietà System.ServiceModel.ICommunicationObject.State è una race condition e non è consigliabile per determinare se riutilizzare o chiudere un canale.
I canali di datagramma non hanno mai esito negativo anche se si verificano eccezioni quando vengono chiusi. Inoltre, i client non duplex la cui autenticazione mediante conversazione protetta non riesce generano di norma un'eccezione System.ServiceModel.Security.MessageSecurityException. Tuttavia, se il client duplex che utilizza una conversazione protetta non viene autenticato, riceve un'eccezione System.TimeoutException.
Per informazioni più complete sull'utilizzo di informazioni sugli errori a livello di applicazione, vedere Specifica e gestione di errori in contratti e servizi. In Expected Exceptions vengono descritte le eccezioni previste e viene illustrato in che modo gestirle. Per ulteriori informazioni su come gestire gli errori durante lo sviluppo di canali, vedere Gestione di eccezioni ed errori.
Blocco dei client e prestazioni
Quando un'applicazione chiama in modo sincrono un'operazione request-reply, il client si blocca fino a quando non viene ricevuto un valore restituito o non viene generata un'eccezione (ad esempio, System.TimeoutException). Si tratta di un comportamento simile al comportamento locale. Quando un'applicazione richiama in modo sincrono un'operazione su un oggetto client o un canale WCF, il client non viene restituito fino a quando il livello del canale non riesce a scrivere i dati nella rete o fino a quando non viene generata un'eccezione. Sebbene il modello di scambio di messaggi unidirezionale (specificato contrassegnando un'operazione con la proprietà System.ServiceModel.OperationContractAttribute.IsOneWay impostata su true) possa aumentare la capacità di risposta di alcuni client, le operazioni unidirezionali possono anche creare blocchi, a seconda dell'associazione e dei messaggi già inviati. Le operazioni unidirezionali riguardano esclusivamente lo scambio di messaggi. Per ulteriori informazioni, vedere Servizi unidirezionali.
I grandi blocchi di dati possono rallentare l'elaborazione dei client, indipendentemente dal modello di scambio di messaggi. Per informazioni su come gestire questi problemi, vedere Dati di grandi dimensioni e flussi.
Se l'applicazione deve eseguire altre operazioni durante il completamento di un'operazione, è consigliabile creare una coppia di metodi asincroni sull'interfaccia di contratto del servizio implementata dal client WCF. Il modo più semplice per ottenere questo risultato consiste nell'utilizzare l'opzione /async nell'ServiceModel Metadata Utility Tool (Svcutil.exe). Per un esempio, vedere Procedura: chiamare operazioni del servizio WCF in modo asincrono.
Per ulteriori informazioni sul miglioramento delle prestazioni dei client, vedere Applicazioni client di livello intermedio.
Abilitazione dell'utente alla selezione dinamica di credenziali
L'interfaccia IInteractiveChannelInitializer consente alle applicazioni di visualizzare un'interfaccia utente che consente all'utente di scegliere le credenziali con cui viene creato un canale prima dell'avvio dei timer di timeout.
Gli sviluppatori di applicazioni possono utilizzare un'interfaccia IInteractiveChannelInitializer inserita in due modi. L'applicazione client può chiamare il metodo System.ServiceModel.ClientBase.DisplayInitializationUI o System.ServiceModel.IClientChannel.DisplayInitializationUI (o una versione asincrona) prima di aprire il canale (approccio esplicito) o chiamare la prima operazione (approccio implicito).
Se si utilizza l'approccio implicito, l'applicazione deve chiamare la prima operazione su un'estensione ClientBase o IClientChannel. Se chiama un elemento diverso dalla prima operazione, viene generata un'eccezione.
Se si utilizza l'approccio esplicito, l'applicazione deve eseguire i passaggi seguenti in ordine:
- Chiamare il metodo System.ServiceModel.ClientBase.DisplayInitializationUI o System.ServiceModel.IClientChannel.DisplayInitializationUI (o una versione asincrona).
- Quando vengono restituiti gli inizializzatori, chiamare il metodo Open sull'oggetto IClientChannel o sull'oggetto IClientChannel restituito dalla proprietà System.ServiceModel.ClientBase.InnerChannel.
- Chiamare le operazioni.
È consigliabile che le applicazioni di alta qualità controllino il processo dell'interfaccia utente adottando l'approccio esplicito.
Le applicazioni che utilizzano l'approccio implicito richiamano gli inizializzatori dell'interfaccia utente, ma se l'utente dell'applicazione non risponde entro il periodo di timeout di invio dell'associazione, viene generata un'eccezione quando viene restituita l'interfaccia utente.
Vedere anche
Attività
Procedura: accedere a servizi WCF con un contratto unidirezionale o request/reply
Procedura: accedere ai servizi con un contratto duplex
Procedura: accedere a WSE 3.0 Service con un client WCF
Procedura: utilizzare ChannelFactory
Procedura: chiamare operazioni del servizio WCF in modo asincrono