Passaggio dei parametri
Principali metodi di passaggio di parametri & procedure,
SOAP & CORBA
Java Remote Method Invocation
Luca Colombi & Fabio Fazio
Luca Colombi
Passaggio dei parametri:
principali metodi di passaggio

Esistono 4 principali metodi per
passare parametri:
 Call-by-value
 Call-by-reference
 Copy-restore
 Call-by-name
2
l-value ed r-value

Due modi per riferirsi al significato-valore di una stessa
espressione:
Il suo l-value (left-value):
si riferisce alla locazione rappresentata dall'espressione
a sinistra del simbolo d’assegnazione:



a[i] := 5+2
(l ≈ location)
Il suo r-value (right-value):
si riferisce al risultato dell’espressione a destra del
simbolo d’assegnazione:


a[i] := 5+2
(r ≈ result)
3
Parametri attuali e formali


Ci può essere confusione tra parametro inteso come
"parametro ricevuto dalla funzione chiamata" e
parametro come "parametro passato dalla funzione
chiamante".
Avremo allora due modi di vedere un parametro:
Parametro attuale: è il parametro che la funzione
chiamante passa alla funzione chiamata, nel contesto
della funzione chiamante.
Parametro formale: è il parametro che la funzione
chiamata riceve, nel contesto dell'esecuzione della
funzione chiamata.
4
Call By Value



E' usata per default in C ed in Pascal.
I parametri attuali sono valutati, ed il loro r-value
è passato alla procedura chiamata.
Il Call-by-value può essere implementato come
segue:
Un parametro formale è trattato esattamente come un
nome locale, così una locazione per il parametro
passato viene riservata nel record d'attivazione della
procedura chiamata.
2. Per ogni parametro attuale, il chiamante ne valuta l'rvalue e lo mette nella locazione del corrispondente
parametro formale.
5
1.
Call By Reference


Quando i parametri sono passati per riferimento,
il chiamante passa alla procedura chiamata un
puntatore per ognuno dei parametri passati.
Il Call-by-reference può essere implementato
come segue:
Se un parametro attuale è un nome o un'espressione
con gia’ un l-value (locazione) proprio, allora il suo lvalue è passato direttamente come parametro.
2. Altrimenti, se il parametro attuale non ha un l-value,
l'espressione è valutata e salvata in una nuova
locazione, e l'indirizzo della nuova locazione è
passato come parametro.
1.
6
Emulare il Call By Reference
con il Call By Value
Una procedura chiamata per valore può
cambiare lo stato della sua procedura
chiamante attraverso variabili globali
oppure attraverso puntatori esplicitamente
passati come valori.
 Utilizzando il passaggio di valori per
accedere direttamente a locazioni fuori
della visibilità della funzione chiamata, si
crea di fatto un passaggio per riferimento.

7
Copy-Restore



Si tratta di una via di mezzo tra il Call-by-value e il
Call-by-reference.
E' usato in Ada e da alcune implementazioni del
Fortran, mentre altre usano il Call-By-Reference.
Può essere implementato come segue:
1.
2.
Prima che il controllo passi alla procedura chiamata, gli r-value
dei parametri attuali sono valutati.
I valori già di tipo r-value vengono passati alla procedura
chiamata come per il call-by-value.
In più, i parametri attuali che hanno un l-value proprio vengono
determinati prima della chiamata.
Prima che il controllo ritorni, gli r-value dei parametri formali
sono ricopiati negli l-value dei rispettivi parametri attuali,
usando gli l-value calcolati prima della chiamata.
I parametri che non avevano l-value al momento di essere
passati non vengono ricopiati.
8
Esempio di caso in cui il programma si comporta
diversamente a seconda che il passaggio sia Copy-Restore
o Call By Reference:
program copyout(input,output);
//variabile globale
var a : integer;
procedure unsafe(var x, : integer);
begin
x := 2;
//Call-By-Reference: sia 'x' che 'a' prendono r-value 2.
//Copy-Restore: 'x' vale 2, 'a' verrà aggiornato al ritorno dalla procedura.
a := 0;
//Call-By-Reference: sia 'x' che 'a' prendono r-value 0.
//Copy-Restore: 'a' vale 0 e viene aggiornato subito perchè è una variabile globale, 'x' resta 2.
end;
//Call-By-Reference: nessun cambiamento: 'a' resta con r-value 0.
//Copy-Restore: 'a' prende l'ultimo valore di 'x', cioè 2.
begin
a := 1;
unsafe(a);
writeln(a);
//Viene stampato a seconda che si usi il Copy-Restore: “2” o il Call-By-Reference: “0”
9
end.
Call By Name

Call-By-Name è usato per il passaggio
parametri dell'Algol e per l’uso delle macro in C:
1.
2.
3.
La procedura è trattata come se ci fosse una macro,
cioè il suo corpo viene sostituito alla corrispondente
chiamata nella procedura chiamante, con i parametri
attuali sostituiti letteralmente (per nome) dai
parametri formali.
Questa sostituzione è chiamata Macro-Expansion o
In-Line-Expansion.
I nomi locali della procedura chiamata vengono
mantenuti distinti dai nomi della procedura
chiamante, rinominando sistematicamente ogni
nome locale con un nuovo nome distinto.
I parametri attuali vengono chiusi tra parentesi se
necessario per preservare la loro integrità.
10
Luca Colombi
Parametri di tipo procedura


Alcuni linguaggi permettono di dichiarare variabili di
tipo procedura o funzione.
Un esempio: Oberon
Pascal
Modula
Oberon

Oberon è un linguaggio degli anni ’90,
discendente del Pascal e orientato agli oggetti,
che permette la dichiarazione e il passaggio di
variabili di tipo funzione, nelle modalità Call-ByValue e Call-By-Reference.
11
Passaggio by-value e by-reference
(variable)

Passaggio di una funzione per valore:


La variabile di tipo funzione passata può essere usata
all’interno della funzione chiamata ma non subisce modifiche
permanenti.
Passaggio di una funzione per riferimento:


La variabile di tipo funzione passata può essere usata
all’interno della funzione chiamata, in più può ricevere
l’assegnamento di un’altra funzione dello stesso tipo, che al
ritorno dalla funzione chiamata rimane al posto di quella passata
come parametro attuale.
Il tipo della funzione sostituita deve coincidere con quello della
funzione che la sostituisce, cioè i tipi, il numero e la posizione
dei parametri delle due funzioni devono coincidere.
12
Java
Remote Method
Invocation
Fabio Fazio
Java
Remote Method Invocation
RMI: goal



Rendere trasparente l’invocazione remota di
metodi su oggetti Java che risiedono su
diverse Virtual machines
Offrire un modello distribuito che preservi
maggiormente la semantica degli oggetti Java
Rendere il piu’ semplice possibile la scrittura
di applicazioni distribuite
14
Java
Remote Method Invocation
Architettura RMI
15
Java
Remote Method Invocation
Architettura RMI


Il sistema RMI e` costituito da tre livelli per
supportare flessibilità nella comunicazione
Ogni livello ha le sue interfacce di
comunicazione con relativi protocolli

stub (e skeleton) layer: canale di comunicazione tra
clients e server
 remote reference layer: supporto di diversi protocolli
di invocazione tipo Unicast e Multicast
 transport layer: supporta la comunicazione a basso
livello, tipo TCP/IP
16
Java
Remote Method Invocation
RMI
Simile all’invocazione di metodi locali
I parametri dei metodi possono anche essere
oggetti (grazie al meccanismo di Serializzazione)
ma
 I Client interagiscono con interfacce di oggetti (stub)
e non con la loro implementazione (che sta nella VM
remota)
 I parametri vengono passati per copia, non per
referenza (passaggio per referenza solo dentro a
una VM)

17
Java
Remote Method Invocation
RMI in pratica


L’oggetto sulla JVM Client desidera inviare un
messaggio all’oggetto sulla JVM Server.
L’oggetto sulla JVM Server terminata l’esecuzione
restituisce l’oggetto come valore di ritorno oppure
solleva un’eccezione
Parametri
18
Java
Remote Method Invocation
Passaggio dei parametri
Client
invocazione
metodo
e invio
parametri
Stub
rete
parametri
originali
Skeleton
Server
serializzazione dei
parametri (marshalling)
marshalling
trasmissione dati serializzati
invio dati
in rete
unmarshalling
ricezione dei
parametri ed
inizio
elaborazione
decodifica dei parametri
(unmarshalling)
copia dei parametri
originali
19
Java
Remote Method Invocation
Ritorno dei risultati
Client
elaborazione
dei parametri
e calcolo del
risultato
marshalling
invio dati
in rete
Stub
rete
serializzazione del
risultato (marshalling)
Skeleton
Server
risultato
originale
trasmissione dati serializzati
unmarshalling
ritorno del
risultato della
elaborazione
decodifica del risultato
(unmarshalling)
copia del
risultato originale
20
Java
Remote Method Invocation
Marshalling (1/3)



Processo che trasforma un oggetto in
memoria in una espressione serializzabile
Si applica agli oggetti che vengono passati al
metodo dell’oggetto remoto come parametro,
ed al valore che il metodo ritorna
Nel caso del passaggio di parametri il
marshalling avviene nello Stub, nel ritorno dei
risultati avviene nello Skeleton (Stub Server)
21
Java
Remote Method Invocation
Marshalling (2/3)


I tipi semplici e gli oggetti meno complessi
vengono serializzati direttamente
Gli oggetti complessi richiedono invece un
procedimento diverso
 si
serializzano ricorsivamente i membri
dell’oggetto
 si serializza l’oggetto


Si crea così una copia dell’oggetto
parametro su cui lavorerà il server remoto
Lavorando su cloni non è possibile una vera
e propria interazione “by reference”
22
Java
Remote Method Invocation
Marshalling (3/3)


E’ necessario interagire su oggetti
serializzabili, quindi non legati ad una
rappresentazione propria del sistema operativo.
Esempio


la classe Java.awt.Image non è serializzabile, perché
rimanda alla descrizione delle immagini propria dei
singoli sistemi operativi
E’ qundi necessario che gli oggetti parametro e
l’oggetto risultato implementino l’interfaccia
java.io.Serializable
23
Java
Remote Method Invocation
Unmarshalling



E’ il procedimento opposto rispetto al
Marshalling: trasforma rappresentazioni
serializzate in oggetti “vivi”, in memoria
I parametri serializzati dallo Stub in fase di
richiamo dei metodi vengono decodificati dallo
Skeleton, i valori di rirorno codificati dallo
Skeleton vengono decodificati dallo Stub
Valgono le stesse considerazioni sulla
serializzazione degli oggetti fatte parlando del
marshalling
24
Java
Remote Method Invocation
Aspetti avanzati di Java RMI

Modalità avanzate di passaggio
parametri.
 passaggio
by value.
 passaggio by remote reference.
Remote callback.
 Oggetti server che implementano
interfacce multiple.

25
Java
Remote Method Invocation
Passaggio parametri by value





E’ la modalità comune.
Viene passata all’oggetto server una copia
speculare dell’oggetto presente nel client.
Se la copia nel server viene modificata da una
interazione indiretta, la copia sul client non ne
rispecchierà le modifiche.
Diventa possibile che le due copie perdano la
congruenza reciproca.
Ciononostante è un approccio valido nella
stragrande maggioranza dei casi.
26
Java
Remote Method Invocation
Passaggio parametri by remote
reference (1/3)



A volte sarebbe comodo mantenere sempre la
coerenza tra le copie dei parametri del server e
del client.
Occorre però un meccanismo che aggiorni
automaticamente gli oggetti del client quando le
rispettive copie presenti nel server subiscono
una modifica.
Occorre allora che la copia presente nel server
notifichi alla rispettiva copia nel client ogni
variazione, cioè un meccanismo RMI con client
e server invertiti.
27
Java
Remote Method Invocation
Passaggio parametri by remote
reference (2/3)

Come implementare tale meccanismo?


Occorre che il client passi al server non una semplice
copia di un oggetto interno, bensì un riferimento ad
un oggetto presente nel server, ovvero uno Stub di
tale oggetto.
Sorge il problema di come ricavare lo Stub di un
oggetto del client.

In quale modo il sistema riconosce un oggetto locale
da un oggetto remoto?

E’ un oggetto remoto un oggetto che estende l’interfaccia
java.rmi.Remote.
28
Java
Remote Method Invocation
Passaggio parametri by remote
reference (3/3)


Quando il meccanismo di marshalling riconosce
un oggetto che implementa l’interfaccia
java.rmi.Remote, invece che inviare una
copia dell’oggetto in questione ne invia uno Stub
Per ottenere un passaggio valori by remote
reference, occorre dichiarare come parametro
formale un’interfaccia che deriva da
java.rmi.Remote
29
Java
Remote Method Invocation
Remote Callback
Allo stesso modo è possibile creare
oggetti che implementino callback.
 Si crea un oggetto remoto che attenda un
dato evento e richiami uno specifico
metodo di un oggetto locale.

30
Java
Remote Method Invocation
Server che implementano
interfacce multiple
È possibile che un oggetto server
implementi più interfacce
 Si può così costruire un oggetto server
che venga istanziato una volta sola e si
comporti diversamente a seconda di come
venga richiamato, ovvero che esporti
metodi diversi a seconda di come vengano
richiesti

31
Luca Colombi
SOAP:
Simple Object Access Protocol




SOAP è progettato come “protocollo leggero per lo scambio di
informazioni in ambiente distribuito”.
In particolare uno dei suoi scopi più utili è come protocollo per
chiamate di metodi remoti tra macchine diverse con sistemi diversi,
fornendo la capacità di integrare sistemi che prima non erano
facilmente in grado di comunicare e scambiarsi risorse.
SOAP prende i parametri di una procedura nella forma nativa
binaria e li trasporta al server remoto come informazioni XML, in
genere tramite protocollo HTTP.
Una volta a destinazione SOAP prende le informazioni XML e le
riporta alla struttura binaria per l’elaborazione.
Alcuni vantaggi particolari di SOAP sono:


essere basato su testo (XML)
non essere legato a soluzioni proprietarie
 I firewall spesso possono essere configurati facilmente per lasciar
passare il protocollo HTTP.
32
Struttura di un pacchetto SOAP

Pacchetto (http)
Header (http)

Soap XML Envelope
Header Soap (opzionale)

Body (il messaggio)
Eventuali elementi personalizzati

Http utilizza l’header per
indirizzare il pacchetto,
notificarne il contenuto (testo
XML) e mantenere altre
informazioni.
L’Envelope SOAP funziona
come wrapper per le
informazioni passate, in questo
caso i parametri delle
procedure.
L’Header SOAP è progettato
per contenere metainformazioni, per esempio un
numero di account o l’algoritmo
usato per crittografare le
informazioni.
Il Body contiene le informazioni
che vogliamo trasportare.
33
Envelope SOAP:
Chiamata tradotta in xml
<?xml version =”1.0” encoding=”utf-8”?>
<soap:Envelope
xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<soap:Header>
<AccountNum xmlns=”http://www.companyurl.com/”>
11285-990
</AccountNum>
</soap:Header>
<soap:Body xmlns=”http://www.companyurl.com”>
<GestisciOrdine>
<Param1>informazioni su Param1..</Param1>
</GestisciOrdine>
</soap:Body>
</soap:Envelope>
34
Envelope SOAP:
Specifiche per la chiamata

Le specifiche SOAP richiedono che il primo
nodo figlio di Body abbia il nome della procedura
remota:


<soap:Body xmlns=”http://www.companyurl.com”>
<GestisciOrdine>
<Param1>informazioni su Param1..</Param1>
…
<ParamN>informazioni su ParamN..</ParamN>
</GestisciOrdine>
</soap:Body>
Ogni discendente del nodo procedura è
denominato in modo simile al parametro
corrispondente.
35
Risposta tradotta in xml
<?xml version =”1.0” encoding=”utf-8”?>
<soap:Envelope
xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<soap:Body xmlns=”http://www.companyurl.com”>
<GestisciOrdineResponse>
<GestisciOrdineResult>
<Val>informazioni su Val</Val>
</GestisciOrdineResult>
</GestisciOrdineResponse>
</soap:Body>
</soap:Envelope>
36
Luca Colombi
CORBA: Common Object
Request Broker Architecture

L’architettura CORBA è un ambiente standard a che permette
l’interoperabilità tra oggetti in sistemi distribuiti eterogenei.
I concetti base di CORBA sono:





Object Services:
Sono una collezione di servizi di sistema predefiniti.
Uno dei principali Object Services è il servizio di naming.
Naming Service:
Il servizio di naming è il principale meccanismo che CORBA rende
disponibile per l’identificazione degli oggetti.
Object Request Broker (ORB):
L’ORB è l’entità che riceve la richiesta dal client, identifica il percorso
necessario per raggiungere l’oggetto target, provvede al suo inoltro e
riporta l’eventuale risposta all’oggetto client.
IDL:
Interface Definition Language: serve a definire interfacce intese come
insieme dei servizi disponibili.
Object implementation:
E l’insieme di codice e dati che effettivamente implementa un oggetto
server.
37
ORB:
chiamata di un metodo





Il client esegue l'invocazione tramite un Object Reference, ottenibile ad
esempio con il servizio di naming, che identifica univocamente l'interfaccia
dell'oggetto server.
Lavorare su un Object Reference ci permette di avere una sorta di
“puntatore in remoto” e a livello di codice specificare le chiamate come locali.
La chiamata può avvenire tramite uno stub o essere costruita
dinamicamente tramite la DII (Dynamic Invocation Interface).
L'ORB localizza l'oggetto server, trasmette i parametri e trasferisce il
controllo al server tramite la server stub (o skeleton).
CORBA ammette anche chiamate in modalita’ oneway:
Sono chiamate remote che non hanno riscontro lato client.
Object implementation
Client
Skeleton (server stub)
Stub
DII
Object Adapter
ORB
38
IDL:
scopo
Gli oggetti CORBA sono visti come
“interfacce” specificate tramite l’IDL
(Interface Definition Language).
 L’Interface Definition Language è un
linguaggio dichiarativo usato per
descrivere le operazioni di un componente
software accessibili esternamente
(interfacce).
 Nell’ambito di CORBA, IDL è usato per
specificare i servizi offerti da ciascun
oggetto server ad eventuali client.

39
IDL:
gli stub

Il mapping dell'IDL in un linguaggio descrive come si
traducono la sintassi e semantica dell'IDL in quel
particolare linguaggio.
Dalla definizione di un'interfaccia in IDL è possibile
derivare (tramite un compilatore che soddisfa il mapping
prescritto da CORBA) gli stub lato client e server.



Il processo di conversione delle strutture dati in messaggi è detto
“marshaling”.
Il processo di decodifica dei dati dal messaggio è detto
“unmarshaling”.
Gli stub realizzano le funzionalità di marshalling e
unmarshalling dei paramentri e del valore di ritorno e
rendono trasparente l’interazione dell'applicazione con
l'ORB.
40
Parametri in IDL

IDL supporta diversi tipi di dato semplici, tra cui Boolean, integer, string,
sequences(array monodimensionali), eccezioni.
Esempio: impiegato.idl
interface impiegato {
long numero();
};
interface registroImpiegati {
impiegato trova(in long imp_num);
};


registroImpiegati.trova(<long>) restituisce l’Object Reference di un oggetto
di tipo impiegato.
IDL permette di specificare le seguenti modalità:
in: il parametro va solo dal client all’oggetto sul server
out: il parametro viene usato come un ulteriore valore di ritorno, non viene
passato dal client all’oggetto sul server ma fa solo il viaggio inverso
 Inout: il parametro è inizializzato dal client e mandato all’oggetto sul server, che
però può rimandarlo indietro modificato.


41
The end