Il protocollo all'inizio può sembrare ostico o comunque complesso per chi è abituato a semplici chiamate GET/POST, ma dopo i primi tentativi e i primi test, tutto si rivela abbastanza semplice e gestibile.

Facciamo però una piccolissima analisi del protocollo.

Il protocollo SOAP
Il protocollo si basa sullo scambio di messaggi tra l'endpoint (punto di accesso al servizio) e il nostro client nel linguaggio di markup XML. Sia le richieste da parte del nostro client che le risposte da parte del fornitore del servizio sono rappresentate da messaggi XML strutturati secondo il protocollo.
L'endpoint deve presentare al fruitore del servizio una descrizione dei metodi, con relativa struttura dei parametri e messaggio di return. Questa "descrizione" del servizio avviene attraverso un messaggio in linguaggio XML definito WSDL. Generalmente il gestore del servizio permette la visualizzazione di tale documento passando come paramentro all'URL dell'endpoint il paramentro WSDL:

Code:

Per approfondimenti in merito al protocollo vi rimando alla voce Wikipedia che risulta ben strutturata.

La mia esperienza
Io ho sviluppato la mia applicazione nel linguaggio PHP poichè tutta la mia analisi dati era finalizzata ad una applicazione WEB, ma esistono svariate librerie per tutti i linguaggi di programmazione.
Inizialmente, preso dalle specifiche di protocollo, ho iniziato il mio scambio messaggi server-client con la libreria CURL di PHP, che mi permetteva di inserire all'interno di una richiesta POST il mio messaggio XML. Questo approccio, per quanto funzionante, risulta molto complesso da gestire e poco veloce poichè richiede una certo tempo per la costruzione dei messaggi XML.
Inoltre esiste già una libreria PHP che ci facilità notevolmente il lavoro "impacchettando" per noi il messaggio.
La libreria SoapClient ci permette di contattare direttamente l'endpoint all'URL del WSDL, e di costruire lato client un set di metodi che provvederanno autonomamente alla chiamata remota del servizio. In pratica la libreria si occupa di instanziare localmente un oggetto che rappresenti l'oggetto remoto che provvede alla generazione dei dati, fornendo tutti i metodi che il Web Service espone.
Un esempio può rendere più chiara la funzione della libreria:
poniamo che il nostro Web Service ci esponga il metodo per la somma di due numeri interi chiamato sum, che accetti come parametri due numeri e abbia come ritorno il numero risultato dalla somma

Code:

In pratica quello che otteniamo con la libreria SoapClient è un oggetto che espone una serie di metodi che non sono altro che i metodi esposti dal Web Service attraverso il WSDL. Tali metodi sono chiamate al Web Service e ritornano il valore di ritorno del Web Service stesso.

Una piccola postilla: gli header
Spesso ci imbattiamo in servizi che necessitano di autenticazione. In questo caso i Web Service generalmente utilizzano un sistema di token per il controllo della sessione. Nel caso del protocollo SOAP e per quanto riguarda il servizio da me utilizzato, i token venivano scambiati con l'endpoint attraverso gli header.
Per settare un header, che il client si occuperà di inviare per ogni richiesta effettuata, la libreria SoapClient mette a disposizione il metodo:

Code:

Spero che questo articolo sfati la difficoltà di utilizzo dei servizi SOAP oriented, e che possa essere di aiuto a qualche sviluppatore.
Buona programmazione a tutti.