Chiamata di procedura remota

In informatica, l'espressione chiamata di procedura remota (RPC, o Remote Procedure Call) si riferisce all'attivazione da parte di un programma di una procedura o subroutine attivata su un computer diverso da quello sul quale il programma viene eseguito. Quindi l'RPC consente a un programma di eseguire subroutine "a distanza" su computer remoti, accessibili attraverso una rete. Essenziale al concetto di RPC è l'idea di trasparenza: la chiamata di procedura remota deve essere infatti eseguita in modo il più possibile analogo a quello della chiamata di procedura locale; i dettagli della comunicazione su rete devono essere "nascosti" (resi trasparenti) all'utilizzatore del meccanismo.

Accezioni del termine modifica

A seconda del contesto, l'espressione RPC viene usata in accezioni leggermente diverse:

può indicare il paradigma di comunicazione fra processi generale descritto sopra, per esempio in contrapposizione ad altri modelli di comunicazione come lo scambio messaggi;
può indicare una API (in senso generale o una API specifica) che consente in questo modo l'interazione fra processi; per esempio, una particolare libreria che lo implementa su una certa piattaforma;
può indicare il protocollo di rete utilizzato per implementare questo meccanismo di interazione.

Paradigma RPC modifica

Il paradigma RPC risulta particolarmente adatto per il calcolo distribuito basato sul modello client-server; la "chiamata di procedura" corrisponde alla "richiesta" inviata dal "cliente", e il "valore restituito" della procedura corrisponde alla "risposta" inviata dal "servente".

Localizzazione del server modifica

Poiché la procedura viene eseguita su un terminale diverso da quello dal quale viene invocata, sorge la necessità di localizzare il server che eseguirà la procedura richiesta. Vi sono tre distinte modalità:

Metodo Statico. L'indirizzo del server (indirizzo IP) viene cablato (scritto) all'interno del client.
Metodo Dinamico. Lo stub del client mentre impacchetta i dati, invia un broadcast nel quale richiede l'indirizzo di un server che può eseguire l'RPC desiderata. Le macchine che ricevono tale messaggio di broadcast e che implementano la procedura, risponderanno al client.
Name Server. Il client consulta un'entità, detta name server, che fornisce una lista di server e dei servizi che ciascuno offre.

Aspetti semantici modifica

Per quanto l'obiettivo ultimo del paradigma RPC sia quello di fornire un meccanismo di chiamata di procedura remota la cui semantica sia essenzialmente equivalente a quella della chiamata di procedura locale (da cui la suddetta trasparenza del meccanismo), tale equivalenza non è mai compiutamente realizzata, a causa delle difficoltà che possono insorgere nella comunicazione su rete (sempre soggetta a fallimento). Non essendovi un unico modo ovviamente "giusto" per gestire queste complicazioni, i meccanismi di RPC possono differire in modo sottile per quanto concerne la semantica esatta della chiamata remota.

Alcuni meccanismi, per esempio, hanno una semantica "at most once" (semantica "al massimo una volta"): in altre parole, una chiamata di procedura remota può fallire (cioè non venire eseguita) ma è garantito che non possa risultare in molteplici attivazioni della subroutine richiamata. L'approccio opposto è rappresentato dalla semantica "at least once", che garantisce che la subroutine venga richiamata almeno una volta (potrebbe quindi accadere che essa sia attivata più volte). La semantica ideale è la "exactly once" (semantica "esattamente una volta"), che coincide con la semantica tradizionale della chiamata a procedura. Nel caso di procedure idempotenti (cioè per le quali una singola attivazione e molteplici attivazioni sono funzionalmente equivalenti), la semantica "at least once" coincide con quella "exactly once".

Altre differenze semantiche fra l'RPC e la chiamata di procedura tradizionale riguardano l'evidente impossibilità, per la procedura richiamata, di produrre effetti collaterali nell'ambiente del chiamante. Anche alcune forme di passaggio parametri, come il passaggio parametri per indirizzo, non sono direttamente applicabili all'RPC, ma possono essere sostituite da concetti semanticamente molto vicini (come la distinzione fra parametri di input e parametri di output).

Interoperabilità e indipendenza dal linguaggio modifica

Un medesimo protocollo RPC può essere reso accessibile attraverso numerose API per diversi linguaggi di programmazione. Questo consente a un programma di richiamare "subroutine" di programmi remoti potenzialmente scritti in altri linguaggi di programmazione. Nella maggior parte dei casi, sistemi RPC di questo genere usano un linguaggio di descrizione di interfacce che consente una rappresentazione formale uniforme dei meccanismi di "subroutine" ("procedura", "funzione", "sottoprogramma", ecc.) forniti dai diversi linguaggi. Esempi di piattaforme che consentono l'interoperabilità di programmi scritti in diversi linguaggi sono la Sun RPC (anche nota come ONC RPC), il Distributed Computing Environment o DCE, le tecnologie DCOM e ActiveX di Microsoft, e il middleware CORBA.

Evoluzioni moderne dell'RPC modifica

Molti meccanismi moderni di RPC sottendono, in modo più o meno esplicito, l'idea che i programmi interagenti siano object-oriented. In tal caso si parla anche, più propriamente, di "invocazione remota di metodi". La remotizzazione dell'esecuzione dei metodi è supportata oggi dai principali linguaggi di sviluppo ad alto livello come Microsoft .NET e Java, resa disponibile rispettivamente da tecnologie come .NET TCP Remoting (2.0), .NET WCF (3.X) e RMI (Remote Method Invocation).

Recentemente, molti produttori hanno creato tecnologie simili all'RPC classica usando XML come IDL (Interface Description Language) e HTTP come protocollo di rete. Questi sistemi vengono chiamati web service. Un esempio celebre è SOAP (Simple Object Access Protocol).

Bibliografia modifica

Voci correlate modifica

Portale Telematica: accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete