30 ebook a un prezzo mai visto!

Risparmia sui tuoi libri preferiti, mentre supporti la community Python Italia

➡️ Scopri gli ebook bundle
Home
Passaggio di parametri a procedure remote in SOAP

07 Marzo 2002

Passaggio di parametri a procedure remote in SOAP

di

La possibilità di utilizzare servizi remoti prevede la necessità utilizzare i parametri elaborativi come strumento per il trasporto dell'informazione

Abbiamo visto nell’articolo precedente come con SOAP sia possibile utilizzare servizi offerti da componenti distribuite. Un servizio è a tutti gli effetti una funzione il cui scopo è un certo tipo di elaborazione. Per svolgere il proprio compito la procedura remota può ricevere una serie di parametri e deve in ogni caso restituire al chiamante un valore di ritorno, di solito si tratta del risultato dell’elaborazione.

Immaginiamo di avere un servizio remoto che riceve in input due numeri e restituisce al chiamante la somma di questi.
Un servizio di questo genere è facilmente implementabile utilizzando, per esempio, il linguaggio C.

int sum(int a, int b)
{
return(a+b);
}

/

I parametri che il servizio remoto utilizza hanno alcune caratteristiche ben definite. Si tratta, per cominciare, di parametri che sono tutti di tipo int, cioè intero.
Analizzando la situazione dal punto di vista del servizio remoto abbiamo due parametri che permettono di ricevere le informazioni per l’elaborazione, si tratta cioè di parametri di tipo [in].
I parametri di questo tipo costituiscono il passaggio “by value”, all’interno del codice chiamante cioè non è possibile aspettarsi che il servizio remoto possa effettuare modifiche ai parametri che gli vengono spediti.

In particolare, analizzando il codice di un qualsiasi utilizzatore del servizio remoto:

main()
{
int x = 10;
int y = 20;

int c = sum (a, b);

/*
in questo punto c = 30
*/
}

/

ci si rendo conto di come, al termine dell’elaborazione il valore di c è uguale a 30 ed il valore dei due parametri spediti al servizio remoto è sempre e comunque uguale a quello che questi avevamo prima della spedizione, qualunque cosa accada all’interno della funzione remota che è stata utilizzata. La motivazione principale di questa considerazione sta nel fatto che alla funzione chiamata vengono spediti soltanto i valori dei parametri, una copia, ecco la spiegazione della terminologia “by value”.

La funzione remota, nel nostro caso, spedisce anche all’indietro un valore, si tratta della somma algebrica dei due parametri ricevuti, pertanto il meccanismo di comunicazione tra chiamante e servizio deve prevedere anche una tipologia di trasporto per questa informazione aggiuntiva.

Questo tipo di situazioni, la più comune nell’ambito del passaggio di parametri ad una funzione, viene gestita in SOAP attraverso una serializzazione di questo genere:

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>


10
20


/

La risposta generata dal servizio remoto ed inviata all’indietro al chiamante sarà di questo tipo:

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>


30


/

Come si può vedere da questi frammenti di codice XML, lo schema di comunicazione è piuttosto semplice e perfettamente comprensibile, l’autoreferenzialità è una delle caratteristiche più interessanti di XML.

Cerchiamo di capire cosa accade a livello di stack delle chiamate sul client e sul server nel caso della request e della response. Lo stack del chiamante, se la funzione fosse locale e non remota, sarebbe formato dalla sequenza dei parametri che verrebbero poi sostituiti, al termine dell’elaborazione, dal risultato.
Nel caso di chiamata ad una funzione remota, invece, lo stack deve essere costruito sul server e non sul client, con tutto quello che ne consegue.

Ecco una schematizzazione della gestione degli stack nella request SOAP.

Ed ecco lo stesso schema al termine dell’elaborazione, cioè nella response.

Come si è visto il caso di trasporto di parametri di tipologia [in], ed il relativo trasporto dei valori di ritorno delle funzioni remote, è piuttosto semplice e segue in maniera lineare il nostro modo di pensare.
Naturalmente le cose si complicano quando cerchiamo di utilizzare i parametri come veicoli bidirezionali per il trasporto di valori, siamo nel caso dell’utilizzo della tipologia “by reference”, oppure quando vogliamo trasmettere strutture complesse e richiedere al metodo remoto la modifica alle caratteristiche delle strutture che gli vengono passate.

Tutto questo, naturalmente, viene gestito da SOAP in maniera trasparente per l’utilizzatore, nei prossimi articoli vedremo come.

L'autore

  • Massimo Canducci
    Massimo Canducci vanta oltre 25 anni di esperienza nel campo dell'innovazione e della digital transformation ed è Chief Innovation Officer per Engineering Ingegneria Informatica. È docente alla Singularity University, l'Università di Torino e l'Università di Pavia, e insegna in master MBA.

Iscriviti alla newsletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Immagine decorativa form newsletter
Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.