SOAP e HTTP

Come visto negli articoli precedenti SOAP è un protocollo applicativo per RPC che utilizza XML come formalismo per il marshalling delle informazioni e può appoggiarsi ad un qualsiasi protocollo di trasporto in grado di gestire semplici flussi di testo.
Le prime versioni della specifica SOAP richiedevano esplicitamente l’utilizzo del protocollo HTTP, ma dalla versione 1.1 tale restrizione è stata eliminata e di conseguenza viene gestito qualsiasi protocollo di trasporto testuale, pertanto sono supportati anche SMTP, NNTP ecc.
In questo contesto, in ogni caso, si incastra a meraviglia il protocollo HTTP a causa delle sue caratteristiche tecniche, in particolare l’utilizzo di request/response e l’assenza di integrazione nel controllo dello stato, ed a causa della sua ampia distribuzione che lo rende il protocollo di trasporto più utilizzato nell’ambiente distribuito per eccellenza, Internet.
Per questi motivi la gran parte delle implementazioni della specifica SOAP che sono disponibili utilizza HTTP come protocollo di trasporto nativo e totalmente integrato nella specifica.

La request SOAP

Una request SOAP è di fatto una request HTTP contenente il payload SOAP.
Riprendendo l’esempio della settimana scorsa è possibile ipotizzare una request SOAP fatta nel modo seguente:

POST /MyApplication HTTP/1.1
Host: www.myhost.com
Content-Type: text/xml; charset=”utf-8″
Content-Length: 1234
SOAPAction: My_Namespace_URI#Calc

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

/

Come si può vedere si tratta di un payload SOAP, codificato naturalmente in XML, trasportato utilizzando una request HTTP.

La response SOAP

Il protocollo HTTP prevede che a seguito di una request fatta utilizzando uno dei classici metodi GET o POST, il server HTTP risponda con una response.
Nel caso specifico della request SOAP si suppone che il server HTTP risponda inserendo all’interno della request un payload SOAP, trasformando di fatto la response HTTP in una response SOAP.

Ritornando all’esempio precedente ci si può attendere che il servizio remoto risponda nel modo seguente:

HTTP/1.1 200 OK
Content-Type: text/xml; charset=”utf-8″
Content-Length: 1234

xmlns:xsi=”http://www.w3.org/1999/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/1999/XMLSchema”>

3

/

Conclusioni

Quello che è successo lo si capisce guardando la request e la response HTTP.
Il client ha richiesto un servizio, in particolare l’esecuzione di un metodo remoto, al server passandogli alcuni parametri, il server ha compiuto l’elaborazione e nella response HTTP produce un payload contenente il risultato dell’elaborazione.
Tutto questo è SOAP, la possibilità di utilizzare servizi remoti messi a disposizione da fornitori esterni oppure parti di applicazione distribuite anche al di fuori delle reti aziendali e tutto questo senza dover inventare tecnologie particolari, ma soltanto elaborando una serie di regole di serializzazione e di comportamento che il richiedente ed il fornitore di un servizio devono rispettare per parlare la stessa lingua.
Detto questo appare chiaro come l’unico limite a tale infrastruttura tecnologica siano i nuovi bisogni applicativi e la fantasia di chi cerchi di soddisfarli.

Una domanda impegnativa: perché nell’esempio della request ho utilizzato il metodo HTTP POST?
Se avessi utilizzato il GET sarebbe stata la stessa cosa?
C’è qualcosa che ci impedisce di utilizzare il GET per SOAP?