|
|
In informatica, l'espressione chiamata di procedura remota (RPC, o Remote Procedure Call) si riferisce all'attivazione di una "procedura" o “funzione” da parte di un programma, nel caso in cui tale procedura venga attivata su un computer diverso da quello sul quale il programma stesso viene eseguito. In altre parole, l'RPC consente a un programma di eseguire procedure "a distanza" su computer "remoti" (accessibili però attraverso una rete). Essenziale al concetto di RPC è anche l'idea di trasparenza: la chiamata di procedura remota deve essere infatti eseguita in modo il più possibile analogo a quella della tradizionale chiamata di procedura "locale"; i dettagli della comunicazione su rete devono essere quindi "nascosti" (resi trasparenti) all'utilizzatore del meccanismo. 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 tornato" della procedura corrisponde alla "risposta" inviata dal "servente". Il calcolo distribuito (distributed computing) utilizza infatti le risorse di diversi computer collegati in rete tra di loro (solitamente attraverso internet) per risolvere problemi computazionali a larga scala. 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. L'approccio opposto è rappresentato dalla semantica "at least once", che garantisce che la procedura 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, ma difficilmente realizzabile. Un medesimo protocollo RPC può essere reso accessibile attraverso numerose interfacce per diversi linguaggi di programmazione. Questo consente a un programma di richiamare "subroutine" ("procedura", "funzione", "sottoprogramma", ecc.) di programmi remoti potenzialmente scritti in altri linguaggi di programmazione. RPC non è di per sé un protocollo o software, ma un insieme di semplici specifiche o paradigmi che vengono poi impiegate all’interno dei middleware e protocolli veri e propri come CORBA. Le RPC in realtà non fanno altro che permettere l’invocazione, l’attivazione di un processo su host remoto. Applicato in un rapporto client-server, il client richiede un qualche servizio sul server inviando la richiesta Request( ) tramite il Communication Module integrato nel processo, il server risponde con una Reply( ) tramite il suo Communication Module. Il meccanismo è estremamente semplice, le possibilità offerte sono limitate così come lo scambio effettivo di dati e l’interazione tra le applicazioni remote. Molti meccanismi moderni di RPC sottendono, in modo più o meno esplicito, l'idea che i programmi distribuiti siano object-oriented (orientati agli oggetti). In tal caso si parla anche, più propriamente, di "invocazione remota di metodi". L'invocazione remota di metodi è uno dei servizi forniti dal linguaggio Java, e in particolare da un suo componente noto come RMI (Remote Method Invocation). Le RMI nascono infatti come evoluzione delle RPC in concomitanza con l’espansione e la sempre maggiore diffusione del modelli di programmazione a oggetti. Le Remote Procedure Call vengono invece ideate verso la metà degli anni ’80, in un ambiente informatico in cui la programmazione a oggetti non esiste ancora. L’unione vincente tra la programmazione ad oggetti e RMI permette una grossa innovazione: la gestione attiva e l’interazione tra oggetti dislocati nello spazio su differenti elaboratori. Gli applicativi locali non solo invocano e utilizzano i propri metodi, ma invocano anche i metodi appartenenti a oggetti di applicazioni remote come se fossero in locale. Quando si programma un’ applicazione distribuita si utilizzano necessariamente ambienti di sviluppo Object Oriented quali C++ o Java, ma il linguaggio di “programmazione” dell’interfaccia ne è indipendente, ed è legato esclusivamente al Middleware impiegato. Quest’ultimo viene in genere incluso nel progetto come una normale libreria, e le varie interfaccie sono descritte in file separati con estensione .idl oppure .odl. Questo perché, per ciascun middleware, sono definiti dei particolari linguaggi per la programmazione di interfacce, gli IDL appunto (Interface Description Language), che possono essere in realtà più o meno simili allo stesso C/C++ o Java a seconda dei casi. Alcuni esempi pratici di linguaggi IDL sono:
Sun XDR, vecchio standard utilizzando per le RPC, ormai obsoleto
DCOM IDL, basato su DCE (Distributed Computer Environment) per le RPC, impiegato nelle tecnologie Microsoft COM e OLE
CORBA IDL, utilizzato per le RMI, uno dei più moderni e versatili
JAVA RMI, utilizzato per le RMI, funzionalità analoghe a CORBA IDL
Per saperne di più consulta i seguenti approfondimenti:
Tutto quanto riportato in questa pagina è a puro scopo informativo personale. Se non ti trovi in accordo con quanto riportato nella pagina, vuoi fare delle precisazioni, vuoi fare delle aggiunte o hai delle proposte e dei consigli da dare, puoi farlo mandando un email. Ogni indicazione è fondamentale per la continua crescita del sito.