Tirando le somme...

Vediamo i pro e i contro che ognuna di queste tecniche ha. Inziamo con i web services "classici".

Pro

• Possibilità di utilizzare web services esposti da qualsiasi sito e sviluppata su qualsiasi piattaforma grazie al protocollo SOAP.

Contro

• Lentezza dovuta all'utilizzo del protocollo SOAP per il trasferimento di grandi quantità di informazioni come file, esempio preso in considerazione in questo tutorial.
• Possibilità di usare solo l'http come trasporto.
• Necessità di installare sul computer su cui vogliamo esporre i nostri web services un web server.

Per quanto riguarda il Remoting:

Pro

• Possibilità di utilizzare il protocollo binario TCP per il massimo delle prestazioni.
• Ideale per comunicazione tra applicazioni .NET.
• Possibilità di utilizzare anche il formato SOAP su HTTP.
• Possibilità di esporre funzioni per il remoting anche su computer senza Web server.

Contro

• Utilizzabile con facilità solo tra applicazione .net.
• Il trasporto su Tcp può essere utilizzato nella maggioranza dei casi solo in Intranet visto che difficilmente si può lasciare porte aperte su Internet.

E per Web services Enhancements 2.

Pro

• Possibilità di usare qualsiasi protocollo
• Nuove funzionalità per la sicurezza, funzioni per la crittografazione, DimeAttachment...

Contro

• Ancora una tecnologia in evoluzione...

Gli esempi allegati

Nel link presente in questa pagina potete scaricare l'esempio trattato in questo articolo. Il file zip contiene quattro progetti:

• esempio_upload: cartella contenente la web application.
• WebServices1: cartella contenente il primo web service.
• WebServices2: cartella contenente il web service enhancement.
• upload: windows form con la classe per il remoting.

Per specificare il percorso dove memorizzare i file inviati, nelle ultime tre applicazioni è presente nel file di configurazione (web.config per le web application e "upload.exe.config" per la window forms) la directory che, ricordo, dovrà avere i permessi in scrittura per il processo ASP.NET.

Per non dover registrare nuovamente i web services nell'applicazione principale, consiglio di impostare in IIS delle directory virtuali con i rispettivi nomi "WebServices1" e "WebServices2".

Conclusioni

Qualunque sia lo scenario in cui ci troviamo il .NET Framework offre una tecnica appropriata. Ormai l'utilizzo delle classi per i web services che ci offre di base il .NET Framework vanno bene anche per essere utilizzate in applicazioni dalla complessità medio-bassa, dove la sicurezza di trasmissione non è fondamentale e si dispone già di tecniche di protezione personalizzate, con una piccola quantità di dati da trasferire. Per gli altri scopi e per un utilizzo veramente ad alto livello, WSE2 facilita notevolmente il lavoro e spinge già la mentalità dello sviluppatore verso il futuro,ovvero Indigo .
Remoting merita una trattazione a sé: l'ideale ambito di suo utilizzo rimangono per applicazioni per Intranet vista la facilità di utilizzo e le prestazioni ai massimi livelli.

Voi da che parte state?

Attenzione: Questo articolo contiene un allegato

Contenuti dell'articolo

• Pagina 1
  • Inviamo i file con il web service
• Pagina 2
  • Remoting
• Pagina 3
  • Web services Enhancements 2
• Pagina 4
  • Tirando le somme...
  • Gli esempi allegati
  • Conclusioni

• Galleria fotografica dinamica con ASP.NET AJAX
• Usare Search come un servizio nei tuoi siti e nei tuoi client
• Mappe nel tuo sito con Virtual Earth
• Integrare Windows Live ID, Contacts e Presence API nelle tue applicazioni
• Introduzione ai cloud based service con Windows Live Services
• Realizzare un custom extender AJAX con ASP.NET 3.5
• Tracciare le modifiche ai dati e allineare i datawarehouse con il Change Data Capture in SQL Server 2008
• Le nuove caratteristiche di IIS 7.0 per sviluppatori e sistemisti