Luca Cabibbo Architettura dei Sistemi Software dispensa asw430 marzo 2018 The core idea od RPC is to hide the complexity of a remote call. Many implementations of RPC, though, hide too much. Sam Newman 1 - Fonti Coulouris, G., Dollimore, J., Kindberg, T., and Blair, G. Distributed Systems: Concepts and Design, fifth edition. Pearson, 2012. Chapter 5, Remote Invocation Tanenbaum, A.S. and Van Steen, M. Distributed Systems: Principles and Paradigms, second edition. Pearson, 2007. Chapter 4, Communication 2
Obiettivi - Obiettivi e argomenti introdurre l invocazione remota e la sua implementazione discutere la semantica dell invocazione remota che differisce in diversi modi dalla semantica dell invocazione locale Argomenti invocazione remota semantica dell invocazione remota discussione 3 * 4 L invocazione remota è una delle principali astrazioni di programmazione distribuita implementate dal middleware supporta interazioni di tipo client-server tra una coppia di componenti consente ad un componente (nel ruolo di client) di chiamare/invocare un operazione di un componente remoto (nel ruolo di server), affinché il componente remoto esegua l operazione richiesta si tratta di un astrazione remota (distribuita) dell invocazione di operazioni locali, che è presente in tutti i linguaggi di programmazione imperativi attenzione: anche se un invocazione remota può essere scritta nel codice in modo simile ad un invocazione locale, ci sono però delle importanti differenze tra invocazione locale e invocazione remota (che verranno discusse in questa dispensa)
L invocazione remota è una delle principali astrazioni di programmazione distribuita implementate dal middleware questo paradigma di programmazione è implementato da molte soluzioni di middleware ad esempio la chiamata di procedure remote (RPC) l invocazione di metodi remoti (RMI) nelle tecnologie a componenti nelle tecnologie a servizi ad es., SOAP e REST questa dispensa discute alcuni aspetti fondamentali dell invocazione remota, facendo riferimento soprattutto alla chiamata di procedure remote (RPC) e, in misura minore, all invocazione di metodi remoti (RMI) tuttavia, quanto viene descritto vale anche per altre implementazioni tecnologiche dell invocazione remota 5 Chiamata di procedure remote (RPC) La chiamata di procedure remote (RPC, Remote Procedure Call) è un astrazione di programmazione distribuita fondamentale è una delle prime soluzioni di middleware realizzate un evoluzione di questa astrazione è comunque disponibile anche nelle soluzioni di middleware più moderne consente ad un componente di chiamare (ovvero, di invocare) una procedura (ovvero, un operazione) di un componente remoto, affinché il componente remoto esegua l operazione richiesta si tratta dunque di una modalità di comunicazione orientata alle azioni, ovvero all invocazione di operazioni remote le operazioni remote possono avere dei parametri inoltre, la loro esecuzione può restituire dei risultati 6
Remote Procedure Call RPC (Remote Procedure Call) In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in another address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. In the object-oriented programming paradigm, RPC calls are represented by remote method invocation (RMI) [Wikipedia, 2018] Attenzione, il fatto che sia scritto nello stesso modo non implica che funzioni nello stesso modo. 7 Invocazione di metodi remoti (RMI) L invocazione di metodi remoti (RMI, Remote Method Invocation) è un estensione orientata agli oggetti della chiamata di procedure remote (RPC) RMI fornisce un servizio di comunicazione tra componenti distribuiti realizzati con tecnologie a oggetti e chiamati oggetti distribuiti o oggetti remoti (discussi in una successiva dispensa) ovvero, oggetti in esecuzione in processi separati in particolare, RMI consente a un oggetto (nel ruolo di client) in esecuzione in un processo di invocare un metodo di un oggetto (nel ruolo di server) in esecuzione in un processo remoto A parte l oggettificazione del modello di programmazione, un invocazione di metodo remoto (in RMI) corrisponde essenzialmente ad una chiamata di procedura remota (in RPC) nel seguito, ignoreremo queste differenze, e parleremo semplicemente di operazioni e di invocazioni remote 8
Un invocazione locale standalone process invocation call Y(arg1, arg2) X Y return value result 9 Un invocazione remota client process invocation server process call Y(arg1, arg2) X Y return value result process boundary 10
Un invocazione remota client process invocation request message server process request call Y(arg1, arg2) X Y return value response result response message 11 Paradigma dell invocazione remota Un invocazione remota da un punto di vista sintattico, l operazione remota Y viene invocata da X come se fosse un invocazione locale in realtà, l operazione Y vive in un processo (il processo server) diverso da quello di X (che vive nel processo client) in prima approssimazione, l esecuzione di un invocazione remota prevede le consuete attività di legame dei parametri, esecuzione dell operazione e restituzione dei risultati che però devono essere svolte in modo remoto l implementazione è basata su un protocollo richiesta-risposta ovvero sullo scambio in rete di un messaggio di richiesta (che codifica l invocazione) e di un messaggio di risposta (che codifica il risultato) 12
Implementazione dell invocazione remota client stub skeleton server call Y(...) prepare request send request request call Y(...) prepare reply send replay decode request local invocation call Y(...) execute operation return value decode reply return value return value response process boundary 13 Implementazione dell invocazione remota Esecuzione di un invocazione remota il client vuole invocare l operazione Y del server remoto l interazione inizia con il modulo client che (nell ambito dell esecuzione dell operazione X) effettua un invocazione dell operazione Y nei confronti dello stub lo stub (o proxy lato client) è un modulo che è un rappresentante locale (nel processo client) del server remoto note: il modulo client effettua un invocazione locale allo stub l operazione Y dello stub è diversa da quella del server dopo di che, lo stub (l operazione Y dello stub) si occupa di preparare un messaggio di richiesta (request) che codifica l invocazione di Y, con i suoi parametri inviare questo messaggio di richiesta al processo server (ad es., tramite socket) altre attività (discusse dopo) 14
Implementazione dell invocazione remota Esecuzione di un invocazione remota lato server, il messaggio di richiesta viene ricevuto (ad es., tramite socket) dallo skeleton lo skeleton (o proxy lato server) è un modulo che è un rappresentante locale (nel processo server) del client remoto lo skeleton si occupa di decodificare il messaggio di richiesta estraendo dalla richiesta l invocazione di Y, con i suoi parametri effettuare l invocazione dell operazione Y nei confronti del modulo server altre attività (discusse dopo) 15 Implementazione dell invocazione remota Esecuzione di un invocazione remota il modulo server, quando riceve l invocazione da parte dello skeleton, esegue l operazione Y richiesta e gli restituisce i risultati dell esecuzione dell operazione nota: il modulo server riceve un invocazione locale dallo skeleton dopo di che, lo skeleton si occupa di ricevere (dal modulo server) i risultati dell esecuzione dell operazione Y preparare un messaggio di risposta (reply) che codifica i risultati dell esecuzione di Y inviare questo messaggio di risposta al processo client (ad es., tramite socket) 16
Implementazione dell invocazione remota Esecuzione di un invocazione remota lato client, il messaggio di risposta viene ricevuto (ad es., tramite socket) dallo stub dopo di che, lo stub si occupa di decodificare il messaggio di risposta estraendo dalla risposta i risultati dell esecuzione di Y restituire i risultati al modulo client infine, il modulo client, dopo aver ricevuto i risultati dell invocazione di Y, prosegue nell esecuzione dell operazione X 17 e proxy remoti Dunque, in un invocazione remota, la comunicazione tra il componente client e il componente server avviene tramite un connettore realizzato come una coppia di moduli intermedi chiamati stub e skeleton lo stub e lo skeleton sono intermediari nella comunicazione sono dei proxy (proxy remoti) un proxy lato client e un proxy lato server Proxy è un design pattern un intermediario, rappresentante di un altro oggetto, di cui ha la stessa interfaccia un proxy [GoF] fornisce un surrogato o un segnaposto per un altro oggetto per controllarne l accesso l uso di una coppia di proxy remoti (stub e skeleton) nasconde al programmatore il fatto che la comunicazione sia distribuita infatti, della comunicazione distribuita (e dei suoi dettagli) si occupano i proxy 18
e proxy remoti In pratica, i due proxy remoti hanno lo scopo di implementare un protocollo richiesta-risposta per supportare l invocazione remota le responsabilità principali dei due proxy remoti sono trasmettere (inviare e ricevere) i messaggi di richiesta e risposta preparare e decodificare i messaggi di richiesta e di risposta con RPC e RMI (così come con altre tecnologie di middleware), questi due proxy vengono generati automaticamente (discusso dopo) ovvero, non devono essere implementati manualmente e individualmente dagli sviluppatori inoltre, l implementazione di questi proxy fa di solito riferimento a delle librerie predefinite (moduli di comunicazione, discussi dopo), che sono responsabili di definire la semantica dell invocazione remota (discussa più avanti) 19 Generazione automatica dei proxy Un aspetto fondamentale di molte tecnologie per l invocazione remota è la generazione automatica dei proxy remoti questa generazione avviene sulla base di un linguaggio per la definizione di interfacce Interface Definition Language (IDL) un compilatore d interfacce client code client process language specific call interface client stub development environment IDL service interface IDL compiler server process language specific call interface server skeleton server code 20
Generazione automatica dei proxy Uso pragmatico e semplificato dell invocazione remota scrittura dell interfaccia del servizio tramite l IDL l interfaccia di un servizio remoto descrive: (i) quali sono le operazioni e (ii) quali sono i tipi usati dalle operazioni (per i parametri e i valori restituiti) compilazione dell interfaccia produce il codice sia dello stub (proxy lato client) che dello skeleton (proxy lato server) del servizio completamento del codice lato server, va implementato il modulo che implementa le operazioni del servizio inoltre, nello skeleton in opportuni segnaposti vanno chiamate queste operazioni lato client, le chiamate alle operazioni vanno rivolte allo stub inoltre, il programma server va mandato in esecuzione sul server, e il servizio va opportunamente registrato 21 Moduli di comunicazione L implementazione dei proxy remoti è di solito basata sull uso di opportuni moduli di comunicazione (fanno parte delle librerie del middleware) cooperanti questi moduli di comunicazione implementano il protocollo richiesta-risposta sottostante all invocazione remota si occupano soprattutto dello scambio dei messaggi di richiesta e di risposta tra i due proxy hanno un ruolo fondamentale nella definizione della semantica dell invocazione remota (discussa più avanti) 22
* Semantica dell invocazione remota L invocazione di un operazione remota viene scritta, sintatticamente, allo stesso modo di un invocazione locale ma la semantica di un invocazione remota è la stessa di un invocazione locale? no, non può essere la stessa, poiché ci sono alcune differenze importanti tra invocazioni remote e locali, tra cui le operazioni sono eseguite in processi e spazi degli indirizzi differenti si possono verificare dei problemi di comunicazione tra i processi distribuiti il legame dei parametri e dei risultati non può essere gestito come nelle invocazioni locali questi aspetti sono discussi qui di seguito 23 - Problemi di affidabilità Nei sistemi distribuiti si possono verificare diversi problemi di affidabilità ad esempio fallimenti nella comunicazione messaggi persi o tramessi male messaggi trasmessi più volte messaggi trasmessi fuori ordine fallimenti nei processi coinvolti ad es., il processo server va in crash A causa di questi (o di altri) problemi, un invocazione remota potrebbe terminare, per il client, anche con la ricezione di un eccezione remota ovvero, la segnalazione di un problema nell invocazione remota 24
Problemi di affidabilità Qui, per semplicità, ci limitiamo a considerare la possibilità di perdere messaggi si noti che l uso di un protocollo di rete a livello di trasporto affidabile (ad es., TCP) nell implementazione di un protocollo richiesta-risposta a livello applicativo, realizzato dai moduli di comunicazione, non garantisce automaticamente l affidabilità di quest ultimo protocollo pertanto, i moduli di comunicazione devono considerare esplicitamente la possibilità di perdere messaggi nella definizione del protocollo richiesta-risposta per gestire l invocazione remota in particolare, i moduli di comunicazione potrebbero essere realizzati in modo da tollerare la perdita di alcuni messaggi le opzioni utilizzate nell implementazione dei moduli di comunicazione hanno impatto sulla semantica dell invocazione remota 25 - Semantica dell invocazione remota Si consideri, nell ambito di un sistema distribuito, un client C che effettua un invocazione remota di un operazione O di un servizio S per gestire questa invocazione remota, nel sistema distribuito vengono scambiati alcuni messaggi in rete e vengono svolte alcune attività (tra cui, forse, l esecuzione dell operazione O) alla fine, ci sono due possibilità per il client C C può ricevere un risultato tra i possibili risultati, includiamo anche la ricezione di un eccezione funzionale oppure, C può ricevere la segnalazione di un eccezione remota a fronte di queste due possibili conclusioni di un invocazione remota, che cosa può capire C di quanto è effettivamente successo nel sistema? la semantica dell invocazione remota ha a che fare appunto con ciò che succede durante un invocazione remota 26
Semantica dell invocazione remota I moduli di comunicazione (m.d.c.), per gestire la possibilità che vengano persi messaggi ovvero, che non vengano ricevuti entro un certo timeout possono implementare il protocollo richiestarisposta in modi diversi (a cui corrispondono semantiche differenti) in particolare, possono usare (oppure non usare) le seguenti opzioni per gestire la perdita di messaggi di richiesta e/o di risposta ciascuna opzione richiede anche le precedenti ripetizione del messaggio di richiesta lato client filtraggio di richieste duplicate lato server ritrasmissione di risposte lato server 27 Semantica dell invocazione remota Opzioni per gestire la perdita dei messaggi ciascuna opzione richiede anche le precedenti ripetizione del messaggio di richiesta lato client il m.d.c. lato client ripete l invio della propria richiesta fino a quando non riceve una risposta o comunque per un numero massimo di volte filtraggio di richieste duplicate lato server il m.d.c. lato client assegna un identificatore alle proprie richieste il m.d.c. lato server mantiene una storia delle richieste ritrasmissione di risposte lato server il m.d.c. lato server mantiene una storia delle richieste e delle risposte quando riceve una richiesta duplicata, anziché rieseguire l operazione, ripete l invio della risposta generata a seguito della prima esecuzione dell operazione 28
Semantica dell invocazione remota L uso combinato di queste opzioni dà luogo a un ventaglio di semantiche differenti per l invocazione di operazioni remoti maybe non ripetere richieste at least once ripeti richieste, non filtrare duplicati, riesegui l operazione at most once ripeti richieste, filtra duplicati, non rieseguire l operazione, ritrasmetti risposte Queste semantiche sono differenti tra loro infatti, nei tre casi, il client di un operazione remota può capire cose differenti quando gli viene restituito il controllo con la restituzione di un risultato o con la segnalazione di un eccezione remota 29 Semantica dell invocazione remota Possibili semantiche per l invocazione remota maybe non ripetere richieste se il client riceve un risultato vuol dire che l operazione è stata eseguita una sola volta se invece il client riceve la segnalazione di un eccezione remota vuol dire o che l operazione non è stata mai eseguita oppure che è stata eseguita (ma solo una volta) at least once ripeti richieste, non filtrare duplicati, riesegui l operazione at most once ripeti richieste, filtra duplicati, non rieseguire l operazione, ritrasmetti risposte La semantica dell invocazione locale è invece exactly once 30
Semantica dell invocazione remota Possibili semantiche per l invocazione remota maybe non ripetere richieste at least once ripeti richieste, non filtrare duplicati, riesegui l operazione se il client riceve un risultato vuol dire che l operazione è stata eseguita una volta oppure anche più volte se invece il client riceve la segnalazione di un eccezione remota vuol dire che l operazione è stata eseguita una volta o anche più volte, oppure che l operazione non è stata mai eseguita at most once ripeti richieste, filtra duplicati, non rieseguire l operazione, ritrasmetti risposte La semantica dell invocazione locale è invece exactly once 31 Semantica dell invocazione remota 32 Possibili semantiche per l invocazione remota maybe non ripetere richieste at least once ripeti richieste, non filtrare duplicati, riesegui l operazione at most once ripeti richieste, filtra duplicati, non rieseguire l operazione, ritrasmetti risposte se il client riceve un risultato vuol dire che l operazione è stata eseguita esattamente una volta se invece il client riceve la segnalazione di un eccezione remota vuol dire o che l operazione non è stata mai eseguita oppure che è stata eseguita (ma solo una volta) è come la semantica maybe, ma con una maggior tolleranza alla perdita di messaggi è la semantica di default per molte tecnologie La semantica dell invocazione locale è invece exactly once
Semantica dell invocazione remota Possibili semantiche per l invocazione remota maybe non ripetere richieste at least once ripeti richieste, non filtrare duplicati, riesegui l operazione at most once ripeti richieste, filtra duplicati, non rieseguire l operazione, ritrasmetti risposte La semantica dell invocazione locale è invece exactly once l operazione viene eseguita esattamente una volta un invocazione può terminare solo con la restituzione di un risultato non è possibile nessuna eccezione remota Si noti che nessuna delle tre semantiche per l invocazione remota corrisponde alla semantica exactly once dell invocazione locale 33 Discussione Semantica Opzioni Se il client riceve un risultato, l operazione è stata eseguita Maybe At least once At most once non ripetere richieste ripeti richieste, non filtrare duplicati, riesegui l operazione ripeti richieste, filtra duplicati, non rieseguire l operazione, ritrasmetti risposte esattamente 1 volta Se il client riceve un eccezione remota, l operazione è stata eseguita 0 o 1 volta 1 o più volte 0 o più volte esattamente 1 volta Exactly once invocazione locale esattamente 1 volta Note 0 o 1 volta maggiore tolleranza ai guasti rispetto a maybe non è possibile invocazione locale 34
Discussione Dunque, ci sono tre possibili semantiche per l invocazione remota queste semantiche differiscono tra loro per ciò che può avvenire durante un invocazione remota, per il grado di tolleranza alla perdita di messaggi e per ciò che è in grado di capire il client di un operazione quando il client riceve un risultato oppure la segnalazione di un eccezione funzionale (la consideriamo la stessa cosa) oppure il client riceve la segnalazione di un eccezione remota nessuna di queste tre semantiche dell invocazione remota corrisponde alla semantica exactly once dell invocazione locale 35 - Prestazioni Un altra differenza tra invocazioni remote e invocazioni locali è relativa ai tempi di esecuzione delle invocazioni remote, a causa dei tempi di comunicazione il protocollo richiesta-risposta su cui si basa l invocazione remota introduce degli overhead, talvolta significativi per lo scambio in rete dei messaggi di richiesta e di risposta per le attività di preparazione e decodifica dei messaggi di richiesta e di risposta per minimizzare la penalizzazione imposta dalle invocazioni remote, bisogna di solito cercare di minimizzare il numero di invocazioni remote pertanto, nella definizione dei servizi distribuiti e delle loro interfacce, è in genere opportuno definire operazione remote con una granularità abbastanza grossa certamente più grossa che non quella di interfacce e operazioni locali 36
- Concorrenza Le operazioni remote possono essere eseguite in modo concorrente tra loro l esecuzione di un operazione remota avviene di solito in un popup thread distinto del componente remoto diversamente dall esecuzione di un operazione locale, che avviene nello stesso thread del chiamante l esecuzione di un operazione remota viene di solito gestita in uno stack dedicato alla chiamata remota diversamente dall esecuzione di un operazione locale, che avviene nello stesso stack del chiamante è possibile l esecuzione concorrente di operazioni remote attenzione, è anche possibile che operazioni eseguite in modo concorrente accedano a risorse condivise tra le diverse esecuzioni nel caso, la possibile concorrenza va gestita in modo opportuno 37 - Legame dei parametri L invocazione di operazioni remote è di solito basata su un meccanismo di legame dei parametri per valore-risultato in cui, in un operazione, si fa distinzione tra parametri di input (in) e risultati/parametri di output (out) Esempio: calcola le radici di un equazione di secondo grado intestazione dell operazione (omettendo i tipi) calcolaradici(in a, in b, in c, out x1, out x2) invocazione dell operazione calcolaradici(1, 4, 2, radice1, radice2) In alcuni linguaggi (come Java), questo tipo di legame è disponibile in una versione limitata con un solo risultato, legato mediante un assegnazione double sqrt(double x) r = sqrt(125) 38
Legame dei parametri per valore-risultato Legame dei parametri per valore-risultato al momento dell invocazione dell operazione, vengono legati i parametri di input i parametri attuali di input (lato client) sono valori questi valori sono usati come valori iniziali per i parametri formali (lato server), che sono variabili quando termina l esecuzione dell operazione, vengono legati i risultati ovvero, i parametri di output i risultati di output (lato server) sono valori questi valori sono usati come valori da assegnare ai parametri attuali di output (lato client), che sono (devono essere) variabili 39 Legame di dati strutturati e oggetti Una differenza importante tra la semantica dell invocazione remota e quella dell invocazione locale è nel modo in cui avviene il legame di dati strutturati come oggetti o record in un invocazione locale, quando un parametro (o un risultato) è un oggetto (o un record, passato per riferimento), allora il valore che viene passato come parametro attuale è in genere un riferimento all oggetto questo ha senso perché i riferimenti (che di solito sono implementati come puntatori) hanno significato nell ambito di un singolo processo inoltre, il passaggio di un riferimento rende possibile effetti collaterali sugli oggetti passati come parametri ovvero, il chiamato può modificare l oggetto passato come parametro, e il chiamante può osservare questa modifica oppure, il chiamante può modificare l oggetto che gli è stato restituito, e il chiamato potrà osservare questa modifica 40
Legame di dati strutturati e oggetti Una differenza importante tra la semantica dell invocazione remota e quella dell invocazione locale è nel modo in cui avviene il legame di dati strutturati come oggetti o record in un invocazione remota, invece, quando un parametro (o un risultato) è un oggetto (o un record), allora il valore che viene passato come parametro attuale è in genere una rappresentazione serializzata dello stato dell oggetto quella che viene passata è una copia dell oggetto, che l operazione remota ottiene deserializzando la rappresentazione ricevuta il passaggio di una rappresentazione serializzata disabilita la possibilità di avere effetti collaterali sugli oggetti passati come parametri (o restituiti come risultati) poiché l operazione remota opera solo su una copia dell oggetto passato come parametro, eventuali modifiche applicate a questa copia non comportano una modifica diretta dell oggetto originale 41 Serializzazione Serialization In computer science, serialization is the process of translating a data structure or an object state into a format that can be stored (for example, in a file) or transmitted (for example, across a network connection link) and reconstructed later (possibly in the same or in a different computer environment). When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. [Wikipedia, 2018] 42
Legame di dati strutturati e oggetti Un parametro che è un oggetto viene legato per valore il valore è una rappresentazione serializzata dell oggetto questa rappresentazione viene trasmessa e poi ricostruita nel processo remoto alpha(value-object) { type : asw.model.employee, id : 410, firstname : John, lastname : Smith, dept : call alpha( ) } { } type : asw.model.department, id : 992, name : DIA 43 Legame di riferimenti remoti In effetti, in RMI, è anche possibile passare dei parametri che sono dei riferimenti ad oggetti remoti (come discusso meglio in una successiva dispensa) questi parametri possono anche essere legati per riferimento remoto beta(remote-object) call beta( remote reference to remote-object ) in questo caso, l operazione remota potrà effettuare a sua volta delle invocazioni remote sull oggetto remoto passato come parametro sono possibili effetti collaterali in modo analogo a quanto avviene nelle invocazioni locali attenzione però alla proliferazione delle invocazioni remote che possono avere conseguenze negative sulle prestazioni 44 Oggetti distribuiti e invocazione remota
- Invocazione asincrona e callback Un invocazione remota può avere una latenza alta soprattutto se l operazione invocata può avere un durata lunga per questo, sono state definite alcune varianti dell invocazione remota invocazione asincrona il chiamante effettua una chiamata non bloccante dell operazione remota la chiamata restituisce immediatamente un oggetto (chiamato promise oppure future) con cui il chiamante potrà poi accedere al risultato (o all esito) dell operazione invocazione sincrona differita il chiamante effettua una prima chiamata dell operazione remota il server restituisce solo una conferma (ack) il chiamante, successivamente, effettua una seconda chiamata per accedere al risultato (o all esito) dell operazione 45 Invocazione asincrona e callback Un invocazione remota può avere una latenza alta soprattutto se l operazione invocata può avere un durata lunga per questo, sono state definite alcune varianti dell invocazione remota callback il chiamante, al momento dell invocazione remota (asincrona), specifica un operazione (chiamata callback) che l oggetto remoto dovrà invocare per comunicare il risultato (o l esito) dell operazione È però importante osservare che l invocazione remota asincrona è, in un certo senso, una forma di comunicazione sincrona poiché il client e il server devono essere attivi contemporaneamente nella gestione dell invocazione remota dunque, non è una forma di comunicazione asincrona, nel senso che verrà discusso in una successiva dispensa sulla Comunicazione asincrona 46
* Discussione L invocazione remota è un astrazione di programmazione distribuita fondamentale i componenti distribuiti interagiscono mediante l invocazione di operazioni remote (procedure o metodi remoti) le invocazioni remote vengono scritte sintatticamente, nel codice, in modo simile a quelle locali ma la loro semantica è differente, per vari motivi per la possibilità di fallimenti nella comunicazione remota e per il modo in cui vengono gestiti per il tempo richiesto dalla gestione di una chiamata per la concorrenza e l eventuale asincronia delle chiamate remote per come viene effettuato il legame dei parametri e per gli effetti collaterali che si possono verificare (o non verificare) per aspetti legati alla sicurezza (che non sono stati discussi) 47