Remote Procedure Call in SOAP

SOAP è un protocollo applicativo di RPC (Remote Procedure Call) e come tale deve utilizzare servizi remoti chiamandone i metodi pubblici.
Un servizio remoto, per definizione, è una black box a cui vengono passati alcuni parametri elaborativi e da cui ci si aspetta un risultato, tutto questo secondo un’interfaccia nota.
In questo quadro quindi il passaggio dei parametri assume un ruolo chiave, in quanto è il meccanismo attraverso il quale un client può comunicare al server le sue intenzioni i può, di conseguenza, riceverne le informazioni richieste.

Dal punto di vista concettuale non c’è alcuna differenza tra l’utilizzo di chiamate a procedure locali o remote, in quanto si tratta in ogni caso della richiesta di un servizio al server e dalla fornitura dello stesso al client.
Dal punto di vista prettamente tecnico, invece, è chiaro che una chiamata ad un servizio remoto ha una serie di implicazioni che complicano leggermente lo scenario tradizionale.

Una RPC, esattamente come una chiamata a procedura locale, può essere schematizzata nel modo seguente:

• il chiamante inserisce i parametri nello stack di chiamate
• trasferisce il controllo dell’esecuzione alla funzione chiamata
• attende il termine delle operazioni da parte della funzione chiamata

nel frattempo la funzione chiamata:

• prende il controllo del flusso operativo
• estrae dallo stack di chiamate i parametri elaborativi
• esegue l’elaborazione
• inserisce nello stack i risultati dell’elaborazione
• restituisce il controllo al chiamante

Al termine dell’elaborazione da parte della funzione chiamata, il chiamante riprende il controllo dell’elaborazione e si trova sullo stack i valori di ritorno della funzione chiamata.

Questo tipo di flusso è schematizzabile, come si può vedere, utilizzando un qualsiasi linguaggio di programmazione procedurale, in questo caso si utilizza C++.

Se la chiamata avviene localmente, cioè all’interno dello stesso processo oppure tra processi che condividono uno spazio di indirizzamento, lo stack delle chiamate è unico, pertanto vengono aggiunti nuovi elementi sullo stack e, dopo l’esecuzione della chiamata, questi vengono rimossi.
Se si tratta invece di una chiamata remota le cose si complicano in quanto al momento di passare il controllo elaborativo al processo remoto, che è in running su una macchina differente da quella del client ed in ogni caso ha uno spazio di indirizzamento differente, tutti i parametri dell’elaborazione devono essere trasformati in una forma trasportabile utilizzando il protocollo di trasporto che si utilizza. Questa operazione prende il nome di serializzazione o marshalling.

Inoltre ci deve essere uno strato software in grado di ricreare sullo stack di chiamate del server la stessa condizione che si avrebbe sul client se la chiamata al metodo fosse locale. Questa operazione di stack transfert ha un ruolo chiave in ogni meccanismo di RPC in quanto, come vedremo, non è affatto banale creare uno stack di chiamate, anche complesso, in uno spazio di indirizzamento differente da quello dove viene generato in maniera nativa e nel momento in cui si cerca di trasportare dei parametri passati per riferimento è necessario ricreare sul server anche una copia di alcune zone dello spazio di indirizzamento della macchina client.
Naturalmente tutto questo deve essere ripetuto nel momento in cui il flusso elaborativo deve tornare al processo chiamante in modo da fargli trovare sullo stack lo stesso risultato che avrebbe se la chiamata alla procedura fosse stata locale e non remota.

La potenza di RPC sta nel fatto che, in linea generale, il client che richiede il servizio remoto è tenuto ad avere, come unica informazione, l’interfaccia della procedura richiesta:

• il suo nome
• i suoi parametri (numero, disposizione e tipo)
• il tipo del valore di ritorno

Dal punto di vista dell’implementazione non è necessario per il client conoscere i dettagli del servizio remoto. In particolare il sistema operativo su cui gira il servizio ed il linguaggio di programmazione attraverso il quale è stato implementato sono informazioni non essenziali per l’utilizzo del metodo in modalità remota.
Il client non ha nessuna informazione su come il servizio sia implementato o di come venga processato il messaggio di comunicazione, l’unico vincolo essenziale è che ci sia accordo sul formato dei messaggi.

Per ottenere questo tipo di flessibilità la chiamata remota alla procedura deve avvenire utilizzando standard di comunicazione sufficientemente aperti e protocolli di trasporto compatibili con le apparecchiature utilizzate.
Le chiamate remote infatti devono essere serializzate, i loro dettagli di comunicazione cioè devono essere trasformati in un formato che sia comprensibile al server che deve ricevere i parametri per la fornitura del servizio, ci deve cioè essere un protocollo applicativo comune che stabilisca le regole della comunicazione.

In questo scenario SOAP si colloca alla perfezione, in quanto utilizza HTTP come protocollo di trasporto e XML come strumento di serializzazione, due tra gli standard più evoluti, affermati ed utilizzati.

In SOAP il meccanismo di RPC è trasparente al client ed al server.
Il client effettua una chiamata al metodo remoto in maniera del tutto simile a come farebbe se il metodo fosse locale. La chiamata al metodo viene trasformata in un payload XML, inserita in una request HTTP ed inviata al server fornitore del servizio richiesto.

A questo punto il server riceverà la richiesta di servizio codificata secondo le specifiche che anche lui conosce ed è in grado di interpretare, effettuerà la deserializzazione del payload per recuperare i parametri e, dopo aver effettuato l’elaborazione, serializzerà nuovamente i dati di ritorno utilizzando il metodo standard di marshalling.
Il payload di ritorno, inserito all’interno della response HTTP, giungerà al client che, essendo in grado di deserializzarlo, ne ricaverà i risultati dell’elaborazione.

Avendo a disposizione uno strumento software di questo genere è possibile astrarre il concetto di chiamata procedurale e non considerarne i dettagli di posizionamento geografico né quelli di carattere tecnologico, l’unica cosa che il client deve conoscere è l’interfaccia pubblica del servizio che si vuole utilizzare.

Nei prossimi articoli vedremo nel dettaglio come avviene il passaggio di parametri alle funzioni remote utilizzando SOAP.