Architettura di SOAP

SOAP è un protocollo applicativo e consiste di una serie di regole in grado di permettere ad applicazioni distribuite di scambiarsi informazioni e di richiedere l’esecuzione di servizi remoti.
Le applicazioni si scambiano messaggi attraverso un pacchetto informativo che prende il nome di payload, una struttura complessa che ciene descritta utilizzando il linguaggio di marcatura XML.
Non esistono restrizioni, invece, per quanto riguarda il protocollo di trasporto utilizzato, qualsiasi protocollo in grado di trasportare semplice testo può essere utilizzato come protocollo di appoggio per trasportare il payload SOAP.
In realtà, pur non esistendo controindicazioni di sorta verso altro protocolli, in generale si tende a privilegiare HTTP per la sua ampia distribuzione e perché attraverso questo è possibile utilizzare le caratteristiche di request/response che sono tipiche di SOAP.

Ma SOAP a cosa serve?

Il primo obiettivo, come abbiamo detto nell’articolo precedente, è permettere alle applicazioni di rendere disponibili, e di conseguenza utilizzare, servizi remoti, cioè componenti generalizzate che offrano un servizio elaborativo il più possibile generalizzato.
Questo significa, quindi, che da un’applicazione client dovrà essere possibile utilizzare un servizio remoto in maniera trasparente e senza conoscere i dettagli di implementazione che lo riguardano.
Tutto quello che l’applicazione client dovrà fare sarà utilizzare le specifiche di chiamata per il servizio remoto passandogli tutti i parametri elaborativi che gli sono necessari per produrre il risultato dell’elaborazione.

Architettura del payload

Il pacchetto informativo contenente la chiamata al metodo remoto e, successivamente, la relativa risposta prende il nome di payload ed è codificato il XML.
La sua struttura è la seguente:

Si tratta quindi di un documento XML racchiuso all’interno del corpo del messaggio che viene veicolato dal protocollo di trasporto ed è formato dalle seguenti sezioni:

Envelope (obbligatoria)

Si tratta del contenitore che racchiude tutto il payload SOAP, tutto quello che è racchiuso nell’Envelope fa parte del messaggio SOAP, tutto quello che è all’esterno non ne fa parte.

L’Envelope ha la seguente struttura:

…

/

Header (opzionale)

Questa sezione contiene informazioni aggiuntive che possono essere utilizzate dal servizio remoto.
La sezione non è obbligatoria, ma se è presente ci si aspetta che il servizio remoto sia in grado di interpretarle, in caso contrario sarà possibile generare delle eccezioni.
L’Header ha la seguente struttura:

5

/

Body (obbligatoria)

Questa sezione contiene il cuore del messaggio, tutte le informazioni che si vogliono far avere al destinatario.
Il Body ha la seguente struttura:

SOAPENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
1
2
SOMMA

/

La sezione Body può essere considerata il contenitore attraverso il quale viene spedita la parte davvero importante del messaggio applicativo, utilizzando il protocollo di trasporto, tra un’applica-zione e l’altra, oppure tra componenti diversi della stessa applicazione.
Il messaggio SOAP formato dalle parti precedenti è il seguente.

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=”http://www.w3.org/1999/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/1999/XMLSchema”>

5

SOAPENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
1
2
SOMMA

/

Il messaggio precedente ha approssimativamente il seguente significato:
utilizzando il namespace: “http://schemas.xmlsoap.org/soap/envelope/”,
utilizzando l’encoding style: “http://schemas.xmlsoap.org/soap/encoding/”,
utilizzando l’opzione mustUnderstand=”1″,
il client chiede al server l’esecuzione del metodo “Calc “
passandogli come parametri Param1=5, Param2=”2″ e Param3=”SOMMA”.
Il client si aspetta in risposta un messaggio SOAP contenente i risultati dell’elaborazione che sarà probabilmente un numero ottenuto dalla somma degli altri parametri passati al servizio.

Come funziona

Dal punto di vista computazionale, la chiamata precedente è equivalente alla seguente chiamata di funzione:

results =Calc(1,2,”SOMMA”);

/

Il client, conoscendo il servizio remoto e la sua interfaccia, tenta di passare a questi i parametri secondo l’interfaccia pubblica del servizio stesso.
A questo punto, in dipendenza dalle API o dagli oggetti che vengono utilizzati per utilizzare i meccanismi di RPC forniti da SOAP, l’astrazione logica all’interno dell’applicazione si occuperà di verificare che la funzionalità richiesta è in realtà una funzionalità remota.
Il servizio remoto, come vedremo, può restituire il risultato dell’elaborazione oppure un messaggio di errore.

Nel prossimo articolo vedremo come si integra quanto detto fino ad ora con il protocollo utilizzato per il trasporto.
Nelle prossime settimane, invece, scriveremo alcuni client e server SOAP utilizzando vari package di vari produttori diversi, vi invito quindi a tirar fuori qualche idea di servizio che si potrebbe remotizzare.