Scelta delle opzioni di comunicazione in .NET
In .NET Framework sono disponibili numerosi modi per comunicare con oggetti in diversi domini di applicazione, ognuno dei quali progettato in base a un particolare livello di esperienza e flessibilita`. Grazie all'espansione di Internet, ad esempio, i servizi Web XML si sono affermati come un interessante metodo di comunicazione poiche´ sono sviluppati sulla base dell'infrastruttura comune del protocollo HTTP e della formattazione SOAP, che utilizza il linguaggio XML. Questi standard pubblici possono essere utilizzati immediatamente con le infrastrutture Web correnti senza la necessita` di affrontare i problemi relativi all'utilizzo di proxy o firewall.
Poiche´ per eseguire molte applicazioni sono necessarie funzionalita` non supportate dai servizi Web creati mediante ASP.NET, questi ultimi non possono essere utilizzati da alcune applicazioni. Nella sezione seguente sono disponibili le informazioni necessarie per la scelta del tipo di supporto per applicazioni distribuite desiderato.
Scelta tra ASP.NET, Enterprise Services o .NET Remoting
ASP.NET, Enterprise Services e .NET Remoting sono implementazioni di comunicazione interprocesso (IPC, Interprocess Communication). ASP.NET offre un'infrastruttura, ospitata in Internet Information Services (IIS), in grado di gestire correttamente i tipi di base, di supportare alcuni protocolli avanzati per servizi Web, se utilizzata con le estensioni del servizio Web (WSE, Web Service Extensions), e che costituisce un ambiente operativo familiare per gli sviluppatori di applicazioni Web. Enterprise Services e` un'implementazione gestita di COM+ e offre tutta la flessibilita` e la completezza di tale architettura. .NET Remoting, infine, e` un sistema IPC generico ed estendibile, indipendente oppure ospitato in IIS, per lo sviluppo e la distribuzione di applicazioni orientate a oggetti. L'architettura modulare di .NET Remoting consente di utilizzare protocolli personalizzati e formati wire.
La scelta tra i modelli di programmazione deve essere eseguita in base a tre criteri principali, ovvero i requisiti aziendali, le esigenze di integrazione e il modello di programmazione per cui si dispone di un maggiore livello di esperienza. Di seguito vengono elencati inoltre, in ordine di priorita`, alcuni criteri utili per la scelta del tipo di tecnologia per applicazioni distribuite necessaria per le proprie esigenze.
Esigenze di protezione
Tra i modelli di programmazione presi in considerazione, Enterprise Services dispone delle funzionalita` di protezione piu` complete ed e` in grado di soddisfare il maggior numero di esigenze. ASP.NET consente di eseguire l'autenticazione mediante IIS e la crittografia mediante SSL, inoltre risulta particolarmente utile per la protezione di applicazioni Internet. Le funzionalita` di protezione di .NET Remoting, infine, sono state migliorate nell'ultima versione di .NET Framework. Nelle versioni precedenti di .NET Remoting, per crittografare le chiamate o autenticare il client, e` necessario utilizzare un'applicazione HTTP ospitata in IIS, di tipo ASP.NET o .NET Remoting. Nella versione attuale TcpChannel e HttpChannel supportano la crittografia SSPI e l'autenticazione integrata di Windows. IpcChannel supporta inoltre l'autenticazione di Windows e l'impostazione diretta dell'elenco di controllo di accesso (ACL) sulla named pipe. Poiche´ non e` consigliabile utilizzare oggetti remoti in Internet, gli scenari per cui e` necessario utilizzare HttpChannel attualmente non sono numerosi. Se e` necessario eseguire comunicazioni mediante Internet, e` consigliabile utilizzare ASP.NET per creare servizi Web XML.
Nota
Per una maggiore protezione, e` consigliabile esporre gli endpoint di .NET Remoting su canali protetti e di non esporli mai non protetti su Internet.
Interoperativita`
Se e` necessario interoperare tra sistemi operativi diversi, e` consigliabile utilizzare servizi Web XML creati mediante ASP.NET, i cui file consentono di definire la forma e lo stile di comunicazione SOAP in modo notevolmente piu` flessibile rispetto a .NET Remoting. Tale flessibilita` consente di semplificare l'interoperativita` tra piattaforme e client diversi. .NET Remoting, infatti, non e` stato progettato per interoperare con piattaforme diverse da .NET.
.NET Framework Remoting non e` stato progettato per interoperare con servizi Web. Per ulteriori informazioni sulla scelta tra servizi Web e .NET Remoting, vedere la sezione sulla scelta tra servizi Web, .NET Remoting ed Enterprise Services sul sito Web relativo alle procedure ottimali per le prestazioni (informazioni in lingua inglese) e la sezione sulla guida alle regole per la scelta tra servizi Web, Enterprise Services e .NET Remoting sul sito Web relativo al miglioramento delle prestazioni e della scalabilita` delle applicazioni .NET (informazioni in lingua inglese).
Velocita`
Se la velocita` di elaborazione e` un fattore determinante, Enterprise Services costituisce la scelta migliore poiche´ consente di ottenere le prestazioni piu` elevate per le applicazioni distribuite. In termini di prestazioni, la differenza tra i file .NET Remoting e i file ASP.NET, dopo l'elaborazione effettiva di un'applicazione, e` trascurabile. Se si utilizza .NET Remoting, le prestazioni migliori su piu` computer sono ottenute mediante TcpChannel con BinaryFormatter. Su un unico computer, e` consigliabile utilizzare IpcChannel con BinaryFormatter.
Scalabilita`
L'hosting dell'applicazione in IIS garantisce la scalabilita` desiderata. Per utilizzare .NET Remoting in modo indipendente sarebbe necessaria la creazione di un'infrastruttura personalizzata per le proprie esigenze di scalabilita`. Se intende utilizzare IIS con .NET Remoting per aumentare il livello di scalabilita`, e` consigliabile prendere in considerazione l'ipotesi alternativa di utilizzare servizi Web creati mediante ASP.NET.
Utilizzo delle funzionalita` di Common Language Runtime
Poiche´ Enterprise Services e .NET Remoting sfruttano i vantaggi offerti dai client .NET, e` possibile utilizzare in un'applicazione le funzionalita` seguenti di .NET che non sono disponibili in un servizio Web XML creato mediante ASP.NET:
Interfacce
CallContext
Proprieta`
Indicizzatori
C++
Fedelta` ai tipi tra applicazioni client e server
Se queste funzionalita` sono considerate di importanza critica, scegliere Enterprise Services quando possibile e quindi .NET Remoting.
Progettazione di applicazioni orientate a oggetti
Gli oggetti di Enterprise services e di .NET Remoting possono essere considerati oggetti effettivi. E` pertanto possibile utilizzare nell'applicazione le seguenti funzionalita` orientate a oggetti che non sono disponibili in ASP.NET:
Riferimenti a oggetti remoti
Numerose opzioni per l'attivazione di oggetti
Gestione dello stato orientata a oggetti
Gestione distribuita della durata degli oggetti
Se queste funzionalita` sono considerate di importanza critica, scegliere Enterprise Services quando possibile e quindi .NET Remoting.
Protocolli di trasporto o formati wire personalizzati. Se e` necessario disporre del supporto per protocolli di trasporto personalizzati, ad esempio User Datagram Protocol (UDP) o per formati wire personalizzati, ad esempio CSV, .NET Remoting rappresenta l'unica architettura modulare in grado di soddisfare queste esigenze.
Comunicazioni tra domini di applicazione diversi. Se e` necessario disporre del supporto per comunicazioni tra oggetti in domini di applicazione diversi all'interno dello stesso processo, deve essere utilizzata l'architettura .NET Remoting.
Nella sezione seguente e` disponibile un breve riepilogo di alcune differenze tra i servizi Web XML creati mediante ASP.NET, lo spazio dei nomi System.Net e .NET Remoting.
Servizi Web XML
I servizi Web XML creati mediante ASP.NET funzionano in modo efficiente se vengono create applicazioni ASP (Active Server Pages) utilizzando il modello di applicazioni Web e il runtime HTTP di ASP.NET, che integra un potente supporto in Microsoft Visual Studio .NET. L'infrastruttura basata su servizi Web XML consente di creare in modo semplice componenti che saranno utilizzati da altre applicazioni o di utilizzare componenti creati da parti diverse mediante l'utilizzo di protocolli, formati e tipi di dati piu` appropriati per le applicazioni Web. L'esatta fedelta` dei tipi tra diversi computer non e` supportata ed e` possibile passare solo alcuni tipi di argomenti. Per ulteriori informazioni, vedere Servizi Web creati mediante ASP.NET e client di servizi Web XML.
Spazio dei nomi System.Net
E` possibile utilizzare le classi nello spazio dei nomi System.Net per creare una struttura di comunicazione a partire dal livello di socket. Con le classi System.Net e` anche possibile implementare protocolli di comunicazione e formati di serializzazione inseribili nell'architettura remota. Per ulteriori informazioni, vedere Programmazione di rete.
Enterprise Services
Basato sull'infrastruttura di .NET Remoting, Enterprise Services offre la completezza e la flessibilita` del modello a oggetti distribuito COM+, incluso un supporto per le transazioni distribuite su larga scala.
.NET Remoting
In .NET Remoting sono disponibili gli strumenti necessari per qualsiasi scenario di comunicazione completo che includa i servizi Web XML. Con .NET Remoting e` possibile eseguire le operazioni elencate di seguito.
Pubblicare o utilizzare servizi in qualsiasi tipo di dominio di applicazione, ovvero un'applicazione console, un Windows Form, IIS, un servizio Web XML o un servizio Windows.
Mantenere una completa fedelta` a un sistema di tipi di codice gestito nelle comunicazioni con formattazione binaria, incluso il supporto per tipi generici.
Nota
I servizi Web XML utilizzano la formattazione SOAP, che non mantiene tutti i dettagli dei tipi.
Passare gli oggetti per riferimento e tornare a un determinato oggetto in un determinato dominio di applicazione.
Controllare direttamente le caratteristiche di attivazione e la durata degli oggetti.
Implementare e utilizzare canali o protocolli di terze parti per estendere la comunicazione in modo da soddisfare specifiche esigenze.
Partecipare direttamente al processo di comunicazione per creare le funzionalita` desiderate.
Vedere anche
Altre risorse
Oggetti remoti
Cenni preliminari su .NET Framework Remoting
Esempi di codice di .NET Remoting
Opzioni avanzate di .NET Remoting