Tutti i web services implementati con ASP.NET (e/o WSE) adottano SOAP. Se però dobbiamo fare una critica a SOAP allora possiamo dire che è un protocollo a volte troppo 'pesante' per quello che deve fare. Perchè avere un header ed un body se mi server spedire solamente un'informazione banale ? Non basterebbe l'XML (per mantenere comunque l'interoperabilità) senza quegli elementi ed attributi SOAP ?
Questa domanda se la pongono in tanti, ed ecco il perchè di REST e POX. Ma allora perchè SOAP ?
E' bene definire che cosa si intenda per protocolli di integrazione. I protocolli di integrazione (inteso flusso di messaggi fra due applicazioni) si dividono in due grandi categorie: protocolli applicativi e protocolli di infrastruttura.
I protocolli applicativi hanno a che fare con il contenuto di dominio del messaggio. In WCF il protocollo applicativo è identificato dal contratto, in WSDL è la portType (rappresentata dalla classe marcata con WebServiceAttribute in ASP.NET), ma può anche essere pensato come l'RSS oppure POX.
I protocolli di infrastruttura invece riguardano tutta la parte dei servizi a valore aggiunto, quale la sicurezza, affidabilità, ecc ecc. Si pensi appunto a SOAP, WS-Security, ecc ecc.
Ora, se abbiamo bisogno di un certo livello di sicurezza, di affidabilità, di gestione della sessione, di transazionalità, ecc ecc allora SOAP è la scelta giusta. Se invece ci basta il contenuto, nudo e crudo, senza servizi aggiuntivi (e trasparenti al contratto) allora SOAP è la soluzione giusta.
Ovviamente ci serve un modello di programmazione univoco, in quanto non ci è permesso perder tempo nel passare da una tecnologia all'altra perdendo la compatibilità del nostro codice...
Ovviamente, tutto questo WCF lo permette :-)