Comunicazione asincrona con i servizi Web XML
Questo argomento è specifico di una tecnologia legacy. Servizi Web XML e client di servizi Web XML devono essere creati attualmente tramite Windows Communication Foundation.
La comunicazione asincrona con un servizio Web segue i due modelli di struttura di chiamata al metodo asincrona specificati da .NET Framework. Prima di approfondire i dettagli, tuttavia, è importante notare che un servizio Web non deve essere scritto specificamente per gestire richieste asincrone da chiamare in modo asincrono.
Wsdl.exe e il modello di struttura asincrona del .NET Framework
Quando lo strumento del linguaggio di descrizione dei servizi Web (Wsdl.exe) genera una classe proxy client per accedere a un particolare servizio Web, esso fornisce alla classe proxy due meccanismi di comunicazione asincrona con ogni metodo del servizio Web. Il primo meccanismo è rappresentato dal modello Begin/End. Il secondo meccanismo è il modello di programmazione asincrona basato sugli eventi disponibile nella versione 2.0 di .NET Framework. Per una breve descrizione dell'utilizzo dei modelli con i servizi Web, vedere le sezioni seguenti. Per i dettagli completi su entrambi i modelli, vedere Asynchronous Programming Design Patterns.
Il modello della chiamata di Begin/End
Wsdl.exe crea automaticamente tre metodi per ogni operazione (un metodo del servizio Web in ASP.NET) pubblicata nel Servizio Web. Un metodo è per l’accesso sincrono; gli altri due per l’accesso asincrono. Questo rimane vero anche in caso di una sola implementazione sincrona del metodo del servizio Web. Nella tabella seguente vengono descritti i tre metodi:
| Nome del metodo nella classe proxy | Descrizione |
|---|---|
<NameOfWebServiceMethod> |
Invia un messaggio per il metodo del servizio Web denominato <NameOfWebServiceMethod> in modo sincrono. |
Begin<NameOfWebServiceMethod> |
Avvia la comunicazione asincrona di un messaggio con un metodo del servizio Web denominato <NameOfWebServiceMethod>. Il client istruisce il metodo Begin per l’avvio dell’elaborazione della chiamata al servizio, ma viene restituito immediatamente un valore. Il valore restituito non è il tipo di dati specificato dal metodo del servizio Web, ma piuttosto un tipo che implementa l'interfaccia IAsyncResult. |
End<NameOfWebServiceMethod> |
Termina una comunicazione asincrona di un messaggio con un metodo del servizio Web denominato <NameOfWebServiceMethod>, restituendo il valore risultante dalla chiamata al metodo del servizio Web. |
I metodi Begin e End seguono la convenzione di denominazione per il modello di struttura asincrono di .NET Framework. Il modello di struttura richiede che siano presenti due metodi asincroni con tale denominazione per ogni metodo sincrono.
Si può considerare ad esempio una classe del servizio Web PrimeFactorizer con un metodo del servizio Web per la ricerca di fattori primi, con la firma seguente:
public long[] Factorize(long factorizableNum)
Sulla base dell’input, tale metodo ha potuto impiegare un periodo di tempo relativamente prolungato per portare a termine l’elaborazione. Si tratta pertanto di un buon esempio di quando sarebbe consigliabile che il client del servizio Web provvedesse a chiamare il metodo del servizio Web in modo asincrono.
Qualora Wsdl.exe utilizzasse il servizio Web come input per la generazione di codice del proxy del client (utilizzando la stringa di query ?wsdl per un servizio Web ASP.NET), ne risulterebbe la creazione di metodi con le firme seguenti:
public long[] Factorize(long factorizableNum)
public System.IAsyncResult BeginFactorize(long factorizableNum, System.AsyncCallback callback, object asyncState)
public long[] EndFactorize(System.IAsyncResult asyncResult)
Implementazione di un client di servizio Web che realizza una chiamata asincrona al metodo utilizzando il modello Begin/End
In che modo il client può sapere quando chiamare il metodo End? Esistono due tecniche per implementare un client che svolga questa funzione, come definito da .NET Framework:
Tecnica wait: utilizzare uno dei metodi della classe WaitHandle per fare in modo che un client rimanga in attesa del completamento delle azioni svolte dal metodo.
Tecnica di callback: passa una funzione di callback nel metodo Begin, che viene quindi chiamato per recuperare i risultati una volta che il metodo ha completato l’elaborazione.
Nota: indipendentemente dalla tecnica prescelta dal client per comunicare in modo asincrono con un servizio Web, i messaggi SOAP inviati e ricevuti risultano identici ai messaggi SOAP generati mediante il metodo sincrono della classe proxy. Ovvero, sono ancora presenti solo una richiesta SOAP e la risposta SOAP inviate e ricevute attraverso la rete. La classe proxy realizza questa operazione mediante la gestione della risposta SOAP utilizzando un thread differente rispetto al thread utilizzato dal client per chiamare il metodo Begin. Pertanto, il client può continuare a eseguire le altre operazioni del thread, mentre la classe proxy gestisce l’intercettazione e l'elaborazione della risposta SOAP.
Tecnica wait utilizzando il modello Begin/End
La classe WaitHandle implementa metodi che supportano l'attesa per la segnalazione degli oggetti di sincronizzazione: WaitOne, WaitAnye WaitAll. La segnalazione di un oggetto di sincronizzazione è un'indicazione che i thread in attesa di intervento su una risorsa specificata possono accedere alla risorsa. Il client del servizio Web accede a un oggetto WaitHandle tramite la proprietà AsyncWaitHandle dell'oggetto IAsyncResult restituito dal metodo Begin.
Per un esempio di questa tecnica, vedere la sezione relativa all’implementazione di un client asincrono del servizio Web utilizzando la tecnica wait.
Tecnica di callback utilizzando il modello Begin/End
Con la tecnica di callback, una funzione di callback implementa il delegato AsyncCallback che impone la firma:
public void MethodName(IAsyncResult ar)
Per un esempio di questa tecnica, vedere la sezione relativa all’implementazione di un client asincrono del servizio Web utilizzando la tecnica di callback.
Se il callback richiede un contesto sincronizzato o con affinità di thread, viene inviato tramite l'infrastruttura del dispatcher del contesto. In altre parole, il callback potrebbe essere eseguito in modo asincrono rispetto al chiamante per contesti simili. Si tratta precisamente della semantica del qualificatore unidirezionale sulle firme del metodo. Significa che queste chiamate del metodo potrebbero essere eseguite in modo sincrono o asincrono rispetto al chiamante e il chiamante non può avere informazioni sul completamento di tale chiamata al momento di riprendere il controllo dell’esecuzione.
La chiamata del metodo End prima che l'operazione asincrona sia completata bloccherà il chiamante. Il comportamento per una seconda chiamata con lo stesso IAsyncResult restituito dal metodo Begin non è definito.
Client asincroni del servizio Web che utilizzano il modello asincrono basato sugli eventi
Multithreaded Programming with the Event-based Asynchronous Pattern introduce un nuovo modello di programmazione asincrona che utilizza gli eventi per gestire i callback, rendendo più semplice la realizzazione di applicazioni multithreading senza dovere implementare codice multithreading complesso. Per una panoramica del nuovo modello asincrono basato sugli eventi, vedere Event-based Asynchronous Pattern Overview. Per i dettagli sulle implementazioni di client che utilizzano il nuovo modello, vedere How to: Implement a Client of the Event-based Asynchronous Pattern.
Per conoscere come compilare un servizio Web utilizzando il modello basato sugli eventi, vedere Procedura: implementare un client del servizio Web asincrono basato sugli eventi tramite ASP.NET 2.0.
Vedere anche
Attività
Procedura: implementare un client del servizio Web asincrono tramite la tecnica Wait
Procedura: implementare un client di servizio Web asincrono tramite la tecnica di callback.
Procedura: eseguire una chiamata asincrona da un client del servizio Web
Concetti
Compilazione di client dei servizi Web XML
Linee guida di progettazione per servizi Web XML creati tramite ASP.NET