Scelta delle opzioni di comunicazione in .NET
Con l'introduzione di .NET Framework 3.0 e Windows Communication Foundation (WCF), diverse tecnologie sono state accorpate in un unico modello di programmazione. WCF funge da versione futura di Enterprise Services, servizi Web ASMX, WSE, MSMQ e .NET Remoting. Nell'argomento seguente viene applicato .NET Framework 2.0. Per ulteriori informazioni WCF e .NET Framework 3.0, vedere: Windows Communication Foundation.
In .NET Framework vengono fornite molte modalità di comunicazione con oggetti in domini di applicazione diversi, ognuno progettato con un particolare livello di competenza e flessibilità. Ad esempio, la crescita di Internet ha reso i servizi Web XML un modo di comunicazione appetibile perché i servizi Web XML sono basati sull'infrastruttura comune del protocollo HTTP e della formattazione SOAP, che utilizza XML. Questi sono standard pubblici e possono essere utilizzati immediatamente con le infrastrutture Web correnti senza preoccuparsi di problemi di proxy o di firewall.
Dal momento che molte applicazioni necessitano di funzionalità che i servizi Web creati utilizzando ASP.NET non supportano, alcune applicazioni non possono utilizzare i servizi Web ASP.NET. Utilizzare la sezione seguente per decidere quale tipo di supporto per applicazioni distribuite si desidera per l'applicazione.
ASP.NET, Enterprise Services, o .NET Remoting
ASP.NET, Enterprise Services e .NET Remoting sono implementazioni della comunicazione interprocesso (IPC). In ASP.NET è fornita un'infrastruttura, ospitata da Internet Information Services (IIS), che gestisce bene i tipi di base, supporta alcuni protocolli avanzati di servizi Web (in caso di utilizzo con estensioni del servizio Web (WSE)) ed è familiare agli sviluppatori di applicazioni Web. Enterprise Services è un'implementazione gestita di COM+ e fornisce tutta la flessibilità e ricchezza dell'architettura COM+. .NET Remoting è un sistema IPC generico ed estendibile che può essere auto-ospitato o ospitato in IIS per sviluppare e distribuire applicazioni orientate a oggetti distribuite. L'architettura di .NET Remoting permette protocolli e formati di trasmissione personalizzati.
La scelta tra i modelli di programmazione deve essere guidata da tre criteri principali: requisiti aziendali, requisiti di integrazione e il modello di programmazione che si conosce meglio. I criteri seguenti (elencato in ordine di priorità) potranno consentire di scegliere il tipo adatto di tecnologia di applicazione distribuita:
Requisiti di sicurezza
Dei tre modelli di programmazione, Enterprise Services ha il set di funzionalità di sicurezza più ricco e si rivela adatto nella maggior parte delle situazioni. ASP.NET fornisce l'autenticazione tramite IIS e crittografia tramite SSL ed è utile per la sicurezza di applicazioni Internet. La sicurezza di .NET Remoting è stata migliorata con l'ultima versione di .NET Framework. Nelle versioni precedenti di .NET Remoting, quando è necessario crittografare le chiamate o autenticare il client, è necessario utilizzare un'applicazione basata su HTTP ospitata in IIS, sia che si tratti di un'applicazione ASP.NET o di un'applicazione .NET Remoting. Nella versione corrente, TcpChannel e HttpChannel supportano la crittografia SSPI e l'autenticazione integrata di Windows. IpcChannel supporta anche l'autenticazione di Windows e l'impostazione diretta dell'elenco di controllo di accesso (ACL) sulla named pipe. Dal momento che non è consigliato utilizzare oggetti remoti in Internet, ci sono poche situazioni che necessitano di HttpChannel. Se è necessario comunicare attraverso Internet, è consigliato l'utilizzo di ASP.NET per creare servizi Web XML.
.gif "8119f66k.note(it-it,VS.100).gif")
Nota:Per motivi di sicurezza, è consigliabile esporre endpoint .NET Remoting tramite canali sicuri. Non esporre mai endpoint .NET Remoting non sicuri a Internet. Interazione
Se è necessario interoperare tra sistemi operativi diversi, sarà necessario utilizzare servizi Web XML creati con ASP.NET. Rispetto a .NET Remoting, i file ASP.NET danno molta più flessibilità nel definire la forma e lo stile delle comunicazioni SOAP. Questa flessibilità può rendere più agevole l'interazione fra piattaforme e client diversi. .NET Remoting non è stato ideato per l'interazione con piattaforme diverse da .NET.
.NET Framework Remoting non è stato ideato per interagire con servizi Web. Per ulteriori informazioni sulla scelta tra servizi Web e .NET Remoting, vedere "Come scegliere tra servizi Web, comunicazione remota e Enterprise Services" in Riepilogo delle procedure di prestazione consigliate, e Linee guida per la scelta fra servizi Web, Enterprise Services e .NET Remoting.
Velocità
Se la velocità è un fattore importante, Enterprise Services fornisce le migliori prestazioni per le applicazioni distribuite. C'è poca differenza in termini di prestazione tra file .NET Remoting e ASP.NET dopo che un'applicazione richiede un'elaborazione reale. Se si utilizza .NET Remoting, TcpChannel con BinaryFormatter vanta le prestazioni migliori su più computer. Sullo stesso computer è consigliabile utilizzare IpcChannel con BinaryFormatter.
Scalabilità
Ospitare l'applicazione in IIS fornisce la scalabilità di cui si ha bisogno. Per fare da host in .NET Remoting, è necessario compilare la propria infrastruttura scalabile. Se si sta considerando di utilizzare IIS con .NET Remoting per guadagnare scalabilità, è preferibile considerare l'utilizzo di servizi Web creati con ASP.NET.
Utilizzo delle funzionalità di Common Language Runtime
Enterprise Services e .NET Remoting, sfruttano client .NET in modo che sia possibile utilizzare nell'applicazione le funzionalità .NET non disponibili in un servizio Web XML creato utilizzando ASP.NET, tra cui:
Interfacce.
CallContext.
Proprietà.
Indicizzatori.
C++.
Fedeltà dei tipi fra applicazioni client e server.
Se queste funzionalità sono strettamente necessarie, scegliere Enterprise Services, se possibile, o .NET Remoting, come seconda scelta.
Progettazione di applicazioni orientate a oggetti
Gli oggetti Enterprise Services e .NET Remoting sono oggetti e possono essere trattati come tali. Di conseguenza, nell'applicazione è possibile utilizzare le seguenti funzionalità orientate a oggetti a cui ASP.NET non ha accesso:
Riferimenti di oggetto a oggetti remoti.
Molte opzioni di attivazione di oggetti.
Gestione dello stato orientata a oggetti.
Gestione di durata degli oggetti distribuita.
Se queste funzionalità sono strettamente necessarie, scegliere Enterprise Services, se possibile, o .NET Remoting, come seconda scelta.
Trasporti o formati di trasmissione personalizzati
Se è necessario supportare trasporti personalizzati (ad esempio, User Datagram Protocol (UDP)) o formati di trasmissione personalizzati (ad esempio, CSV), .NET Remoting è l'unica architettura modulare che può soddisfare questi requisiti.
Comunicazioni condivise tra applicazioni
Se è necessario supportare la comunicazione tra oggetti in diversi domini di applicazione all'interno dello stesso processo, sarà necessario utilizzare .NET Remoting.
Nelle sezioni seguenti è incluso un breve riepilogo di alcune delle differenze tra servizi Web XML creati utilizzando ASP.NET, lo spazio dei nomi System.Net Enterprise Services e .NET Remoting.
Servizi Web XML
I servizi Web XML creati utilizzando ASP.NET vanno bene se si compilano applicazioni ASP utilizzando il modello di applicazione Web e il runtime HTTP ASP.NET, che include il supporto in Microsoft Visual Studio .NET. Con l'infrastruttura del servizio Web XML, è possibile creare componenti da utilizzare in altre applicazioni o utilizzare componenti che altre applicazioni hanno creato utilizzando protocolli, formati e tipi di dati adatti alle applicazioni basate sul Web. Non è supportata l'esatta fedeltà dei tipi fra diversi computer ed è possibile passare solo alcuni tipi di argomenti. Per ulteriori informazioni, vedere Servizi Web XML creati mediante ASP.NET e tramite client di servizi Web XML.
Spazio dei nomi System.Net
È possibile utilizzare le classi nello spazio dei nomi System.Net per compilare un'intera struttura di comunicazione dal livello socket. È inoltre possibile utilizzare le classi System.Net per implementare protocolli di comunicazione e formati di serializzazione da collegare all'architettura .NET Remoting. Per ulteriori informazioni, vedere Network Programming.
Enterprise Services
Enterprise Services espande l'infrastruttura .NET Remoting per fornire tutta la completezza e flessibilità del modello a oggetti distribuito COM+, incluso il supporto per transazioni a vasta distribuzione.
.NET Remoting
.NET Remoting fornisce gli strumenti per gestire qualsiasi situazione di comunicazione che includa servizi Web XML. Utilizzando .NET Remoting, è possibile:
Pubblicare o utilizzare servizi in qualsiasi tipo di dominio applicazione, sia che quel dominio sia un'applicazione console, Windows Form, IIS, un servizio Web XML, o Windows Service.
Mantenere la fedeltà di sistema dei tipi di codice completamente gestito in comunicazioni in formato binario, incluso il supporto per i tipi generici.
Nota:I servizi Web XML utilizzano la formattazione SOAP che non mantiene tutti i dettagli relativi ai tipi. Passare oggetti per riferimento ed eseguire restituzioni a un particolare oggetto o in un particolare dominio di applicazione.
Controllare direttamente caratteristiche di attivazione e durata degli oggetti.
Implementare e utilizzare canali o protocolli di terze parti per soddisfare specifici requisiti di comunicazione.
Partecipare direttamente al processo di comunicazione per creare la funzionalità di cui si ha bisogno.
Vedere anche
Altre risorse
.NET Remoting
Panoramica di .NET Framework Remoting
Esempi di .NET Remoting
.NET Remoting avanzato
Windows Communication Foundation