Paolo Pialorsi

MS-SOAP Toolkit

Oggi, dal momento che è sabato, ho il tempo di leggere un po' di blog , sistemare qualche articolo da pubblicare su DevLeap ... insomma come ogni buon informatico, dedico il sabato al "relax tecnologico" :-) e non ai doveri professionali.

Ho letto tra i vari blogs di amici e colleghi un post di Andrea Saltarello che mi ha stimolato qualche riflessione.

Non sono mai stato un amante del SOAP Toolkit e francamente non mi dispiace più di tanto pensare di doverlo mettere in soffitta o in cantina :-)...

Da tempo ormai consiglio ai miei clienti di usare il motore di Web Service client di ASP.NET anche da applicazioni legacy VB6, se possibile ovviamente. Basta infatti costruire una buona libreria proxy verso il web service, renderla COM-Interoperabile - via COM-Interop appunto - e usarla da VB6.

Quali sono i vantaggi maggiori di un simile approccio?

• si rispetta WS-I lavorando in modalità documenti/literal
• si possono usare, in modo semplice, paradigmi di chiamata asincrona sul client
• si ha una migliore gestione degli errori
• si posso sfruttare comodamente le SOAP Extension e i SOAP Header
• se proprio dovesse servire possiamo anche utilizzare WSE1 o WSE2 per renderi sicuri i servizi
• abbiamo un unico strato software di interazione (dal punto di vista del client) con i servizi, quindi sia client VB6 che .NET avranno una sola libreria proxy di riferimento da rilasciare e mantenere

E quali sono gli svantaggi più significativi?

• dobbiamo avere .NET anche sul client (ma questo ormai è sempre meno problematico)
• dobbiamo conoscere .NET (direi che ora di smettere di fare i conservatori e anche se siamo tutti presi da mille progetti, dobbiamo trovare il tempo di aggiornarci!)
• dobbiamo fare attenzione a come si parleranno l'applicazione legacy VB6 e il componente .NET per evitare di avere problemi di interoperabilità COM<->.NET

A voi la scelta ... io il SOAP Toolkit l'ho già messo in soffitta da un po' !