Oggetti utilizzabili e non utilizzabili in remoto
Questo argomento è specifico di una tecnologia legacy mantenuta per una questione di compatibilità con le applicazioni esistenti di versioni precedenti e non è consigliato per il nuovo sviluppo. Le applicazioni distribuite devono ora essere sviluppate utilizzando Windows Communication Foundation (WCF).
È importante ricordare che un oggetto creato in un dominio applicazione, e quindi specifico dello stesso, può essere chiamato direttamente da quel dominio, ma deve verificarsi qualche evento prima che quell'oggetto sia disponibile al di fuori del dominio. Non tutti i tipi di oggetto possono essere pubblicati o utilizzati in maniera efficiente attraverso limiti di dominio; pertanto, è necessario decidere quale tipo di oggetto si desidera pubblicare in base ai requisiti dell'applicazione. Ai fini di applicazioni distribuite, esistono due categorie di oggetti: oggetti non utilizzabili in remoto e oggetti utilizzabili in remoto.
Oggetti non utilizzabili in remoto
Alcuni oggetti non possono lasciare il proprio dominio applicazione; di loro non viene mai effettuato il marshalling perché non dichiarano un metodo di serializzazione. Questi oggetti non utilizzabili in remoto sono progettati per essere utilizzati all'interno dello stesso dominio applicazione nel quale sono creati e vi si accede sempre direttamente da quel dominio applicazione. La maggior parte delle classi di base presenti nella libreria di classi .NET Framework sono oggetti non utilizzabili in remoto. Non è possibile copiare oggetti non utilizzabili in remoto o rappresentarli in un altro dominio applicazione. È possibile accedere a questi oggetti solo dal loro dominio applicazione originale.
Oggetti utilizzabili in remoto
È possibile accedere a oggetti utilizzabili in remoto dall'esterno del loro dominio applicazione o contesto utilizzando un proxy, o possono essere copiati e queste copie passate fuori del dominio applicazione o contesto. Alcuni oggetti utilizzabili in remoto, in sostanza, vengono passati per riferimento, mentre altri per valore.
Gli oggetti utilizzabili in remoto sono oggetti che funzionano bene in un ambiente ampiamente distribuito. Esistono due tipi principali di oggetti utilizzabili in remoto:
Oggetti con marshalling per valore, che vengono copiati e passati dal dominio applicazione.
Oggetti marshalling per riferimento per i quali viene creato un proxy utilizzato dal client per accedere all'oggetto in modalità remota.
Oggetti marshalling per valore
Gli oggetti marshalling per valore (MBV) dichiarano le proprie regole di serializzazione (o implementando ISerializable per implementare la propria serializzazione, o venendo contrassegnati con SerializableAttributeche comunica al sistema di serializzare automaticamente l'oggetto) ma non estendono MarshalByRefObject. Il sistema .NET Remoting fa una copia completa di questi oggetti e la passa al dominio dell'applicazione chiamante. Una volta che la copia è nel dominio dell'applicazione del chiamante, le chiamate alla copia finiscono direttamente in quella copia. Gli oggetti MBV passati come argomenti, inoltre, vengono passati anche per valore. Oltre a dichiarare l'attributo SerializableAttribute o implementare ISerializable, non è necessario eseguire altre operazioni per passare istanze della classe per valore attraverso limiti dell'applicazione o del contesto.
.gif "h8f0y3fc.note(it-it,VS.100).gif") Nota: |
|---|
| A partire dalla versione 1.1 della libreria .NET Framework, l'infrastruttura .NET Remoting non deserializza automaticamente alcuni tipi sul server. Se l'applicazione tenta di passare un tipo che non è serializzato automaticamente, è necessario impostare il livello di deserializzazione server su Full prima che il server possa deserializzare e utilizzare l'oggetto MBV. Per ulteriori informazioni, vedere Deserializzazione automatica in .NET Remoting. |
Utilizzare oggetti MBV quando per motivi di prestazioni o di elaborazione ha senso spostare lo stato completo dell'oggetto e della qualsiasi funzionalità eseguibile nel dominio dell'applicazione di destinazione. In molti scenari, ciò riduce i round trip lunghi e dispendiosi in termini di risorse fra la rete, i processi e i limiti del dominio applicazione. Gli oggetti MBV vengono anche utilizzati direttamente dall'interno del dominio applicazione originale dell'oggetto. In questo caso, poiché non si verifica nessun marshalling, non viene eseguita alcuna copia e l'accesso risulta efficiente.
Creare un tipo marshalling per valore utilizzando la classe SerializableAttribute a meno che non si stia estendendo una classe che già implementa ISerializable. In questo caso, è necessario implementare ISerializable per il tipo.
Il sistema .NET Remoting utilizza oggetti serializzabili in modo estensivo. Un riferimento a un oggetto in un altro dominio dell'applicazione, rappresentato nel sistema .NET Remoting dalla classe ObjRef, è serializzabile, e deve essere possibile copiarlo esattamente e inviarne la copia a un client. Oggetti che trasferiscono dati, inoltre, sono spesso oggetti serializzabili. Dataset, ad esempio, estende MarshalByValueComponent, che implementa ISerializable.
Eccezioni definite dall'utente in .NET Remoting
Le eccezioni definite dal sistema sono tutti tipi marshalling per valore (implementano l'interfaccia ISerializable ) che, quando generati da un oggetto remoto, vengono copiati automaticamente al chiamante se le configurazioni di .NET Remoting lo consentono. A partire dalla versione 1.1 della libreria .NET Framework, l'elemento <customErrors> deve essere impostato su off per consentire alle eccezioni di confluire nel chiamante.
Per ulteriori informazioni sulla creazione di un tipo di eccezione che può essere generato da un oggetto remoto e intercettato da un chiamante remoto, vedere Procedura: creare un tipo di eccezione generabile da oggetti remoti
Oggetti marshalling per riferimento
Gli oggetti marshalling per riferimento (MBR) sono oggetti utilizzabili in remoto che estendono almeno System.MarshalByRefObject. A seconda del tipo di attivazione dichiarato, quando un client crea un'istanza di un oggetto MBR nel proprio dominio applicazione, l'infrastruttura .NET Remoting crea un proxy che rappresenta l'oggetto MBR e restituisce al chiamante un riferimento a quel proxy. Il client effettua quindi chiamate sul proxy. .NET Remoting effettua il marshalling di quelle chiamate al dominio applicazione dell'oggetto remoto e richiama la chiamata.
| Nota: |
|---|
| Se il client è nello stesso dominio applicazione dell'oggetto MBR, l'infrastruttura restituisce un riferimento diretto all'oggetto MBR al client, evitando il sovraccarico dovuto al marshalling. |
Se un System.MarshalByRefObject viene passato come parametro, diventa un proxy nell'altro dominio applicazione quando la chiamata arriva. Valori restituiti MBR e parametri out funzionano nello stesso modo.
| Nota: |
|---|
| A partire dalla versione 1.1 della libreria .NET Framework, l'infrastruttura .NET Remoting non deserializza automaticamente alcuni tipi sul server. Ad esempio, per ottenere supporto per gli oggetti MBR passati come parametri, è necessario impostare il livello di deserializzazione del server su Full prima che il server possa deserializzare e utilizzare il parametro MBR. Per ulteriori informazioni, vedere Deserializzazione automatica in .NET Remoting. |
È necessario utilizzare oggetti MBR quando lo stato dell'oggetto e qualsiasi funzionalità eseguibile deve restare nel dominio dell'applicazione in cui è stato creato. Ad esempio, un oggetto che ha un campo interno che è un handle del sistema operativo deve estendere System.MarshalByRefObject perché l'handle del sistema operativo non sarebbe significativo in un altro dominio applicazione, in un altro processo o in un altro computer. Un oggetto a volte può essere anche estremamente grande. Potrebbe funzionare su un server affidabile, ma non se inviato via rete a un modem a 33,6 KBps.
Oggetti legati al contesto
Gli oggetti legati al contesto sono oggetti MBR che ereditano da System.ContextBoundObject, che a sua volta eredita da System.MarshalByRefObject. È possibile pensare a un contesto come a una suddivisione di un dominio applicazione che fornisce un ambiente dettagliato per gli oggetti che vi risiedono durante l'esecuzione. Ad esempio, un contesto può garantire che agli oggetti accedano simultaneamente più thread. Ogni dominio applicazione ha un contesto predefinito. La maggior parte del codice gestito crea oggetti e chiama membri direttamente dall'interno dello stesso dominio applicazione utilizzando il contesto predefinito di quel dominio, senza problemi correlati al contesto. Tutti i tipi che ereditano da System.ContextBoundObject sono esposti ad altri contesti (nello stesso dominio o in altri domini) come proxy.
Ad esempio, si supponga di avere un metodo su un tipo che fa parte di una transazione e che quindi è limitato dalle regole specifiche al contesto nel quale è stato creato. Quel tipo dovrà ereditare da System.ContextBoundObject in modo che all'oggetto si faccia accesso dal suo contesto e che il sistema possa applicare le regole relative alle transazioni associate a quell'oggetto e ai suoi metodi. Se viene chiamato un System.ContextBoundObject da un altro contesto all'interno dello stesso dominio applicazione, verrà creato un proxy per il chiamante ma la comunicazione fra contesti non attraversa il sistema del canale, cosa che aumenta l'efficienza delle chiamate in questa situazione.
Dal momento che attraversare ogni limite richiede tempo di elaborazione, è consigliabile determinare i limiti che l'oggetto dovrà attraversare prima di decidere quale tipo di oggetto utilizzabile in remoto dovrebbe essere il server. A oggetti specifici di un particolare contesto è possibile accedere direttamente solo da quel contesto. Lo stesso vale per gli oggetti specifici di un particolare dominio applicazione. Per utilizzare in remoto gli oggetti, il sistema .NET Remoting deve attraversare un limite di contesto, un limite di applicazione, o entrambi, prima di richiamare l'oggetto server dall'interno del limite di cui è specifico. Se non è necessario un controllo di contesto per chiamare l'oggetto, sarà opportuno non fare estendere System.ContextBoundObject dal tipo remoto; System.MarshalByRefObject funziona meglio. Se è necessario il controllo di contesto, sarà opportuno estendere System.ContextBoundObject, ma è necessario capire che il limite aggiuntivo deve essere attraversato prima che la chiamata venga effettuata sull'oggetto.
Ambito di pubblicazione
Sistemi .NET Remoting diversi utilizzano modalità diverse per decidere quali membri e che tipo di membri possano essere utilizzati in modalità remota. .NET Remoting espone oggetti ad altri domini applicazione come se fossero locali, con le eccezioni seguenti:
Membri statici.
Campi e metodi statici non sono mai remoti e l'accesso al campo avviene tramite memoria diretta. Ovvero, .NET Remoting ha sempre a che fare con membri di istanza di qualche tipo.
Campi di istanza e funzioni di accesso.
Per campi di istanza e metodi di funzioni di accesso, il sistema inserisce un controllo a runtime per determinare se l'oggetto è un proxy. Se non è un proxy, l'accesso al campo è diretto. In caso contrario, il proxy fornisce funzioni di accesso al chiamante.
Metodi privati.
I metodi privati non possono essere utilizzati in remoto. Non è possibile eseguire il wrapping e passare un delegato a un metodo privato in modalità remota.
Delegati.
I delegati sono oggetti marshalling per valore. L'oggetto all'interno del delegato può essere qualsiasi tipo di oggetto utilizzabile in remoto: un oggetto serializzabile, un oggetto MarshalByRefObject o un oggetto ContextBoundObject. L'unica eccezione è che un delegato a un metodo di interfaccia non può essere utilizzato in remoto in maniera corretta. Il delegato esegue il wrapping dell'implementazione del metodo di interfaccia, richiedendo le informazioni sul tipo del client da rendere disponibili al server.
Override di metodi su Object.
Per motivi di prestazioni, i metodi virtuali su Oggetto vengono sempre eseguiti localmente nel dominio applicazione dove vengono chiamati. Le chiamate a ciascuno dei metodi seguenti giungono all'oggetto remoto solo quando è stato eseguito l'override di questi metodi sull'oggetto remoto:
Equals
Questo metodo virtuale viene eseguito in modalità remota se è stato sottoposto a override.
GetHashCode
Questo metodo viene eseguito localmente.
ToString
Questo metodo virtuale viene eseguito in modalità remota se è stato sottoposto a override.
Equals (la versione statica)
Questo metodo viene eseguito localmente.
MemberwiseClone
Questo metodo viene eseguito localmente.
Vedere anche
Attività
Procedura: creare un tipo di eccezione generabile da oggetti remoti
Altre risorse
Panoramica di .NET Framework Remoting
Impostazione degli oggetti per essere utilizzabili in remoto