Scelta delle opzioni di comunicazione in .NET
.NET Framework offre vari modi per comunicare con oggetti in diversi domini applicazione, ciascuno progettato avendo in mente un particolare livello di esperienza e flessibilità. Grazie alla crescita di Internet, ad esempio, i servizi Web XML sono divenuti un interessante metodo di comunicazione poiché sono generati sull'infrastruttura comune del protocollo HTTP e della formattazione SOAP, che utilizza XML. Si tratta di standard pubblici utilizzabili immediatamente con le infrastrutture Web correnti senza doversi preoccupare di problemi legati all'impiego di proxy o firewall.
Non tutte le applicazioni devono essere generate con un servizio Web XML, tuttavia, anche a causa delle problematiche relative alle prestazioni legate all'uso della serializzazione SOAP su una connessione HTTP. In questa sezione viene offerto il supporto necessario per una scelta più agevole del tipo di comunicazione tra oggetti desiderata per un'applicazione.
ASP.NET o Remoting
Sia ASP.NET che .NET Remoting sono implementazioni di comunicazione interprocesso. ASP.NET offre un'infrastruttura, contenuta in Internet Information Services (IIS), in grado di gestire correttamente i tipi di base e già nota agli sviluppatori di applicazioni Web. .NET Remoting è un sistema di comunicazione interprocesso generico ed estremamente estensibile che è possibile utilizzare per generare servizi Web XML inseriti in IIS, con tutte le caratteristiche di protezione, scalabilità nonché stato sessione e applicazione di ASP.NET e IIS, o applicazioni in cui si utilizza qualsiasi altro tipo di protocollo di comunicazione o formato di serializzazione.
La scelta tra i due modelli di programmazione è dettata dal tipo di comunicazione necessario e dal modello di programmazione con cui si ha maggiore familiarità. È necessario scegliere il tipo di comunicazione interprocesso e il modello di programmazione che consentano di implementare decisioni nel modo più semplice. Di seguito sono riportati, in ordine di priorità, alcuni criteri per la scelta del tipo di comunicazione interprocesso necessaria, oltre al confronto tra servizi Web XML creati con ASP.NET e servizi Web XML creati con .NET Remoting:
Esigenze di protezione:
Se si desidera proteggere le chiamate, è necessario utilizzare un'applicazione basata su HTTP contenuta in IIS, di tipo ASP.NET o remota, perché sia in ASP.NET che in .NET Remoting vengono utilizzati i servizi di protezione forniti da IIS. In .NET Remoting non vengono forniti servizi di protezione quando l'infrastruttura si trova al di fuori di IIS, ad esempio in un servizio Windows. A differenza dei servizi Web XML creati con ASP.NET, che devono essere contenuti in IIS, .NET Remoting può essere utilizzato in qualsiasi dominio applicazione ma, quando lo si utilizza al di fuori di IIS, occorre fornire le funzioni di protezione necessarie. L'uso di una connessione HTTP non richiede l'impiego del formato di codifica SOAP. È infatti possibile utilizzare la codifica binaria per aumentare la velocità.
Velocità:
.NET Remoting presenta un potenziale vantaggio in termini di prestazioni rispetto ai servizi Web XML creati con ASP.NET, perché consente di utilizzare la codifica binaria e il canale TcpChannel predefinito, che offre le migliori prestazioni di comunicazione interprocesso. È possibile specificare la codifica binaria anche se non si utilizza il canale TcpChannel predefinito adoperando il formattatore binario con la classe HttpChannel, che si avvale della comunicazione POST con IIS o qualsiasi applicazione listener HttpChannel remota. L'impiego della sola formattazione binaria aumenterà notevolmente le prestazioni delle chiamate in remoto, anche se si utilizza HttpChannel. Se non si hanno problemi di protezione, ad esempio nel caso di una piccola applicazione che verrà interamente eseguita all'interno di un firewall, il canale TcpChannel predefinito con formattazione binaria garantirà prestazioni ottimali. Nei servizi Web XML generati con ASP.NET viene sempre utilizzata la codifica SOAP, le cui prestazioni sono di solito inferiori rispetto alla codifica binaria. In situazioni in cui le funzionalità di .NET Remoting non sono necessarie, mentre lo è il protocollo HTTP con i messaggi SOAP, i servizi Web XML generati con ASP.NET forniscono prestazioni migliori.
Interazione:
Se è necessaria l'interazione tra sistemi operativi differenti, verrà probabilmente utilizzato il protocollo di formattazione SOAP, sia con .NET Remoting che con ASP.NET. I servizi Web XML generati con ASP.NET forniscono maggiore flessibilità rispetto a NET Remoting nella definizione della forma e dello stile della comunicazione SOAP. In questo modo si semplifica l'interoperabilità con piattaforme e client diversi. .NET Remoting è ottimizzato per la comunicazione con client .NET, sebbene sia possibile utilizzare un'applicazione remota per l'interoperabilità tra sistemi operativi diversi.
Scalabilità:
Inserendo l'applicazione in IIS si ottiene la scalabilità necessaria, sia con .NET Remoting che con ASP.NET.
Utilizzo delle funzionalità di Common Language Runtime:
Poiché .NET Remoting è in grado di sfruttare al meglio le funzionalità dei client .NET, per un'applicazione remota è possibile utilizzare funzionalità .NET che non sono disponibili per un servizio Web XML generato con ASP.NET. Di seguito sono riportate alcune di queste funzionalità:
- interfacce
- CallContext
- proprietà
- indicizzatori
- estensioni gestite per C++
- fedeltà dei tipi tra applicazioni client e server
- delegati.
Progettazione applicazioni orientata a oggetti:
I servizi Web XML generati con ASP.NET non rappresentano un paradigma di progettazione orientata a oggetti. Si tratta essenzialmente di risorse Web senza informazioni sullo stato, simili alle pagine Web, sebbene da IIS e dall'infrastruttura ASP.NET vengano forniti alcuni servizi di stato. Gli oggetti di .NET Remoting sono oggetti a tutti gli effetti. Di conseguenza, è possibile utilizzare le seguenti funzionalità .NET orientate a oggetti che non sono disponibili per ASP.NET:
- Riferimenti a oggetti remoti
- Diverse opzioni per l'attivazione di oggetti
- Gestione dello stato orientata a oggetti
- Gestione distribuita della durata degli oggetti.
Di seguito viene fornito un breve riepilogo di alcune differenze tra i servizi Web XML generati con ASP.NET, lo spazio dei nomi System.Net e .NET Remoting.
Servizi Web XML
Se si creano applicazioni ASP utilizzando il modello di applicazione Web e si desidera disporre della potenza del runtime HTTP di ASP.NET, incluso un efficiente supporto in Microsoft Visual Studio .NET, i servizi Web generati con ASP.NET rappresentano la soluzione ideale. Con l'infrastruttura dei servizi Web XML, è facile creare componenti utilizzabili in altre applicazioni o utilizzare componenti creati da altri impiegando i protocolli, i formati e i tipi di dati più appropriati alle applicazioni Web. L'esatta fedeltà dei tipi tra diversi computer non è supportata ed è possibile passare solo alcuni tipi di argomenti. Per ulteriori informazioni, vedere Servizi Web XML creati con client di servizi Web XML e ASP.NET.
Spazio dei nomi System .Net
È possibile utilizzare le classi nello spazio dei nomi System.Net per generare una struttura di comunicazione completa da zero. Con le classi System.Net è anche possibile implementare protocolli di comunicazione e formati di serializzazione inseribili nell'architettura remota. Per ulteriori informazioni, vedere Accesso a Internet.
.NET Remoting
.NET Remoting offre gli strumenti necessari per qualsiasi scenario di comunicazione completo, inclusi, tra gli altri, i servizi Web XML. Con .NET Remoting è possibile eseguire le operazioni elencate di seguito.
Pubblicare o utilizzare i servizi in qualsiasi tipo di dominio applicazione, da un'applicazione console, a Windows Form, a Internet Information Services (IIS), a un servizio Web XML o un servizio Windows.
Conservare una completa fedeltà a un sistema di tipi di codice gestito nelle comunicazioni con formattazione binaria.
Nota I servizi Web XML utilizzano la formattazione SOAP, che non conserva tutti i dettagli sui tipi.
Passare gli oggetti per riferimento e tornare a un determinato oggetto in un determinato dominio applicazione.
Controllare direttamente le caratteristiche di attivazione e la durata degli oggetti.
Implementare e utilizzare canali o protocolli di altri produttori per estendere la comunicazione in modo da soddisfare specifiche esigenze.
Partecipare direttamente al processo di comunicazione per creare le funzionalità desiderate.
Vedere anche
Accesso a oggetti in altri domini applicazione mediante .NET Remoting | Cenni preliminari su .NET Remoting | Esempi di comunicazione remota | Comunicazione remota avanzata