Architettura di .NET Remoting

L'infrastruttura di .NET Remoting rappresenta un approccio astratto alla comunicazione interprocesso. La maggior parte del sistema funziona senza richiedere particolari interventi. Gli oggetti che è possibile passare per valore, o copiare, ad esempio, vengono automaticamente passati tra le applicazioni in diversi domini applicazione o su diversi computer. È sufficiente contrassegnare le classi personalizzate come serializzabili per ottenere questo risultato.

La forza effettiva del sistema di comunicazione remota, tuttavia, risiede nella capacità di abilitare la comunicazione tra gli oggetti in vari domini applicazione o processi mediante diversi protocolli di trasporto, formati di serializzazione, schemi di durata e modalità di creazione degli oggetti. Le funzionalità remote, inoltre, consentono di intervenire quasi in qualsiasi fase del processo di comunicazione.

Sia che si implementino alcune applicazioni distribuite o si desideri semplicemente spostare i componenti su altri computer per aumentare la scalabilità del proprio programma, è più semplice considerare il sistema di comunicazione remota come un sistema generico di comunicazione interprocesso con alcune implementazioni predefinite in grado di gestire facilmente qualsiasi scenario. Nella discussione che segue vengono presentate le nozioni di base della comunicazione interprocesso mediante il sistema di comunicazione remota.

Copie e riferimenti

La comunicazione tra processi richiede un oggetto server la cui funzionalità viene fornita ai chiamanti al di fuori del processo, un client che effettua le chiamate sull'oggetto server e un meccanismo di trasporto per condurre le chiamate da un'estremità all'altra. Gli indirizzi dei metodi server sono logici e funzionano correttamente in un dato processo, ma non in un processo client differente. Per risolvere questo problema e consentire al client di chiamare un oggetto server, creare una copia completa dell'oggetto e spostarla sul processo client, da cui è possibile richiamare direttamente i metodi della copia.

Molti oggetti, tuttavia, non possono o non devono essere copiati e spostati in altri processi per essere eseguiti. Gli oggetti di dimensioni molto grandi con molti metodi non costituiscono la scelta ideale per la copia, o il passaggio per valore, in altri processi. Un client richiede in genere solo le informazioni restituite da uno o pochi metodi sull'oggetto server. La copia dell'intero oggetto server, incluse ampie quantità di informazioni interne o strutture eseguibili non legate alle esigenze del client, costituisce uno spreco in termini di larghezza di banda nonché di memoria del client e tempo di elaborazione. Molti oggetti, inoltre, espongono funzionalità pubbliche, ma richiedono dati privati per l'esecuzione interna. La copia di questi oggetti può consentire l'accesso ai dati interni da parte di client non autorizzati, dando origine a potenziali problemi di protezione. Alcuni oggetti, infine, utilizzano i dati che non possono essere copiati in alcun modo comprensibile. Un oggetto FileInfo, ad esempio, contiene un riferimento a un file del sistema operativo, con un indirizzo univoco nella memoria del processo del server. Questo indirizzo può essere copiato, ma non avrà senso in un altro processo.

In queste situazioni il processo server deve passare al processo client un riferimento all'oggetto server e non una copia dell'oggetto. Il riferimento può essere utilizzato dai client per chiamare l'oggetto server. Le chiamate non vengono eseguite nel processo client. Il sistema di comunicazione remota, invece, raccoglie tutte le informazioni sulla chiamata e le invia al processo server, in cui vengono interpretate, l'oggetto server corretto viene individuato e viene effettuata la chiamata all'oggetto server per conto del client. Il risultato della chiamata viene quindi inviato nuovamente al processo client per essere restituito al client. La larghezza di banda viene utilizzata solo per le informazioni critiche, vale a dire la chiamata, gli argomenti della chiamata e qualsiasi valore o eccezione restituita.

Architettura remota semplificata

L'utilizzo dei riferimenti a oggetti per comunicare tra oggetti server e client è il fulcro della comunicazione remota. Dall'architettura remota, tuttavia, viene fornita al programmatore una routine ancora più semplice. Se si configura correttamente il client, è sufficiente creare una nuova istanza dell'oggetto remoto utilizzando new o la funzione di creazione dell'istanza dal linguaggio di programmazione gestito. Il client riceve un riferimento all'oggetto server ed è quindi possibile chiamarne i metodi come se l'oggetto si trovasse nel processo invece di essere eseguito su un altro computer. Il sistema remoto utilizza gli oggetti proxy per dare l'impressione che l'oggetto server si trovi nel processo client. I proxy sono oggetti stand-in che si presentano come oggetti di altro tipo. Quando il client crea un'istanza del tipo remoto, dall'infrastruttura remota viene creato un oggetto proxy che per il client presenta lo stesso aspetto del tipo remoto. Il client chiama un metodo su tale proxy e il sistema remoto riceve la chiamata, la instrada al processo server, richiama l'oggetto server e restituisce il valore restituito al proxy client, il quale restituisce il risultato al client.

Le chiamate remote devono essere trasportate tra il client e il processo server. Se si genera un proprio sistema di comunicazione remota, può essere utile iniziare ad apprendere la programmazione di rete e una vasta gamma di protocolli e specifiche sui formati di serializzazione. Nel sistema .NET Remoting la combinazione delle tecnologie sottostanti richieste per aprire una connessione di rete e utilizzare un particolare protocollo per inviare i byte all'applicazione ricevente è rappresentata come canale di trasporto.

Un canale è un tipo che accetta un flusso di dati, crea un package in base a un particolare protocollo di rete e lo invia a un altro computer. Alcuni canali possono unicamente ricevere le informazioni, altri possono solo inviarle, altri ancora, come le classi predefinite TcpChannel e HttpChannel, possono essere utilizzati in entrambe le direzioni.

Tutti gli aspetti di ogni tipo univoco sono noti al processo server, mentre l'unico aspetto noto al client è l'esigenza di un riferimento a un oggetto in un altro dominio applicazione, forse su un altro computer. Dall'esterno del dominio applicazione del server, l'oggetto è individuato da un URL. Gli URL che rappresentano tipi univoci per il mondo esterno sono URL di attivazione, i quali garantiscono che la chiamata remota viene effettuata al tipo corretto. Per ulteriori dettagli, vedere URL di attivazione.

Progettazione del sistema completo di comunicazione remota

Si supponga di disporre di un'applicazione in esecuzione su un computer e di utilizzare la funzionalità esposta da un tipo memorizzato su un altro computer. Nell'illustrazione seguente viene mostrato il processo generale di comunicazione remota.

Processo di comunicazione remota

Se entrambe le estremità della relazione sono configurate correttamente, un client crea semplicemente una nuova istanza della classe server. Il sistema di comunicazione remota crea un oggetto proxy che rappresenta la classe e restituisce all'oggetto client un riferimento al proxy. Quando un metodo viene chiamato dal client, l'infrastruttura remota consente di gestire la chiamata, di controllare le informazioni sul tipo e di inviare la chiamata sul canale al processo server. Un canale in attesa raccoglie la richiesta e la inoltra al sistema di comunicazione remota del server, che individua, o crea se necessario, e chiama l'oggetto richiesto. Il processo viene quindi invertito, in quanto il sistema di comunicazione remota del server raggruppa la risposta in un messaggio che viene inviato al canale client dal canale server. Il sistema di comunicazione remota del client, infine, restituisce il risultato della chiamata all'oggetto client attraverso il proxy.

Il codice richiesto per questa operazione è minimo, ma è opportuno valutare attentamente la progettazione e la configurazione della relazione. È possibile che il codice non abbia esito positivo, nonostante la correttezza, a causa di un URL o un numero di porta non validi. Per ulteriori informazioni, vedere Configurazione.

Benché questa visione generale del processo di comunicazione remota sia piuttosto semplice, i dettagli possono rivelarsi complessi. Negli altri argomenti elencati di seguito vengono trattati in modo più dettagliato gli elementi principali della comunicazione remota.

Vedere anche

Cenni preliminari su .NET Remoting | Limiti: processi e domini applicazione | Oggetti remotizzabili e non remotizzabili | Attivazione e durata degli oggetti | Canali | Protezione | Configurazione