Condividi tramite

Esecuzione ed elaborazione di chiamate asincrone

  • Articolo

Gli oggetti COM possono supportare chiamate asincrone. Quando un client effettua una chiamata asincrona, il controllo torna immediatamente al client. Mentre il server elabora la chiamata, il client è libero di eseguire altre operazioni. Quando il client non può più procedere senza i risultati della chiamata, può ottenere i risultati della chiamata in quel momento.

Ad esempio, una richiesta per un recordset di grandi dimensioni o complessa può richiedere molto tempo. Un client può richiedere il recordset tramite una chiamata asincrona e quindi eseguire altre operazioni. Quando il recordset è disponibile, il client può ottenerlo rapidamente senza bloccarlo.

I client non effettuano chiamate asincrone direttamente nell'oggetto server. Ottengono invece un oggetto chiamata che implementa una versione asincrona di un'interfaccia sincrona nell'oggetto server. L'interfaccia asincrona nell'oggetto chiamata ha un nome del formato AsyncInterfaceName. Ad esempio, se un oggetto server implementa un'interfaccia sincrona denominata IMyInterface, sarà presente un oggetto chiamata che implementa un'interfaccia asincrona denominata AsyncIMyInterface.

Nota

Il supporto asincrono non è disponibile per IDispatch o per le interfacce che ereditano IDispatch.

 

Gli oggetti server che supportano chiamate asincrone implementano l'interfaccia ICallFactory . Questa interfaccia espone un singolo metodo, CreateCall, che crea un'istanza di un oggetto chiamata specificato. I client possono eseguire query per ICallFactory per determinare se un oggetto supporta chiamate asincrone.

Per ogni metodo in un'interfaccia sincrona, l'interfaccia asincrona corrispondente implementa due metodi. Questi metodi associano i prefissi Begin_ e Finish_ al nome del metodo sincrono. Ad esempio, se un'interfaccia denominata ISimpleStream ha un metodo Read, l'interfaccia AsyncISimpleStream avrà un Begin_Read e un metodo Finish_Read. Per avviare una chiamata asincrona, il client chiama il metodo Begin_.

Quando si implementa un oggetto server, non è necessario fornire un oggetto chiamata per ogni interfaccia implementata dall'oggetto . Se l'oggetto server implementa l'interfaccia ICallFactory e usa il marshalling standard, un client sottoposto a marshalling può sempre ottenere un oggetto chiamata proxy, anche se non è presente alcun oggetto di chiamata sul lato server. Questo proxy eseguirà il marshalling del metodo Begin_ come chiamata sincrona, il server elabora la chiamata in modo sincrono e il client può ottenere i parametri out chiamando il metodo Finish_.

Viceversa, se un client effettua una chiamata sincrona con marshalling su un'interfaccia per la quale è presente un oggetto chiamata sul lato server, il server elabora sempre la chiamata in modo asincrono. Questo comportamento non sarà evidente per il client, perché il client riceverà gli stessi parametri out e lo stesso valore restituito che avrebbe ricevuto dal metodo sincrono.

In entrambi i casi, l'interazione tra client e server viene sottoposto a marshalling come se la chiamata fosse sincrona: l'output dei proxy sincroni e asincroni è indistinguishable, come è l'output degli stub corrispondenti. Questo comportamento semplifica notevolmente il modello di programmazione sia dei client che dei server. Se un oggetto server implementa ICallFactory, un client sottoposto a marshalling non deve tentare di creare un oggetto di chiamata che potrebbe non essere disponibile per il client, un oggetto di chiamata è sempre disponibile.

Quando il client e il server si trovano nello stesso apartment, l'oggetto server elaborerà qualsiasi chiamata eseguita dal client. Se un oggetto di chiamata non è disponibile, il client deve ottenere in modo esplicito l'interfaccia sincrona e effettuare una chiamata sincrona.

Per ulteriori informazioni, vedi gli argomenti seguenti: