Cristian,

il tuo post è eloquente, ma glissa su alcuni aspetti della realtà dei web service che sono di fatto alla radice del declino di SOAP, soprattutto su servizi mainstream.

Le tue considerazioni sono perfettamente condivisibili se ti metti dalla parte del consumatore di un servizio. Soprattutto se hai a disposizione tool evoluti come Visual Studio che generano decine di linee di boilerplate code per te, è molto semplice ridurre l'utilizzo di un web service SOAP a due linee di codice: crea il proxy, istanzia il proxy.

Facciamo un fast-forward e passiamo a cosa succede quando esce la versione 2.0 del servizio, oppure quando semplicemente devi correggere un baco nel servizio stesso.
Supponiamo per esempio che un parametro intero debba passare da 32 a 64 bit. Niente di drammatico - il cambiamento è perfettamente compatibile con la versione passata.
Grazie a SOAP e al suo strong typing però, il WSDL non è più lo stesso, quindi tutti i client che si basavano sull'interfaccia con l'Int32 non possono usare quella nuova (funzionalmente compatibile) con un Int64. L'unica scelta come fornitore del servizio è tenere entrambi i servizi in vita side-by-side, magari con della logica di thunking che almeno unifichi l'esecuzione.

Dal punto di vista del service provider, SOAP è un incubo. Ti trovi a dovere supportare molto rapidamente una miriade di major e minor versions o a dovere fare degli hack orrendi per incastrare in un dato WSDL cose che non erano lontanamente previste.
Tutto questo con REST sparisce - da cui la sua crescente popolarità.

Che poi il Web 2.0 sia una colossale minestra riscaldata (si faceva AJAX già nel 2000 anche se allora non aveva il nome fico, e REST/XML si chiamava XML over HTTP) è un fatto. Quello che c'è di nuovo è la consapevolezza di utilizzare le tecnologie insieme in un modo più organico.

Saluti

--Alessandro

Vorrei poterti dare l'esempio pratico che ci ha fatto impazzire recentemente - purtroppo devo aspettare ancora qualche mese...
Il problema critico di SOAP è il suo strong typing.
Gli standard WS-* sono belli in teoria, ma a parte quelli più semplici, pochi li usano perché le implementazioni sono molto parzialmente compatibili.

Non è l'unico - un altro dei problemi più divertenti che abbiamo avuto nel passato è il supporto nei tool.

Prendi per esempio gli attributi di tipo List in XSD. In VS se usi C# tutto bene. Ma già se usi C++ sei nei guai - la code generation fallisce. Anche xsd.exe rifiuta quel WSDL (valido in teoria).
Per non parlare di tutti i tool in Java o altre piattaforme non MS.

Se vuoi toccare il problema con mano, basta che punti al WSDL della generazione corrente delle Live Search API (http://soap.search.msn.com/webservices.asmx?wsdl e provi direttamente.

C'è un'altra grossa differenza: costruire la chiamata tramite i parametri di un URL è molto più semplice che costruire un'intera struttura in XML in una request. Per non parlare della prolissità - SOAP è inutilizzabile in ogni scenario dove la banda passante sia critica (per esempio i telefonini).

Saluti

--Alessandro

Questo è un punto sul quale sono completamente d'accordo.
Il problema non è il formato di serializzazione, è l'infrastruttura che lo usa.

WCF è molto versatile perché va al di là del protocollo su cui si basa.

Il problema è che non ci sono troppi framework con quel livello di sofisticazione, e soprattutto quando devi interoperare con sistemi diversi, scegliere oculatamente il formato on the wire diventa importante.

SOAP ha alcuni vantaggi, ma anche grossi problemi, come abbiamo già discusso. REST è un'alternativa di moda e efficace in molti ambiti.
L'ideale per un servizio veramente versatile è offrirli entrambi (magari aggiungendo anche la serializzazione in JSON)


Saluti

--Alessandro