Comunicazione con oggetti distribuiti - Distributed object communication

In un ambiente di elaborazione distribuito, la comunicazione con oggetti distribuiti realizza la comunicazione tra oggetti distribuiti . Il ruolo principale è consentire agli oggetti di accedere ai dati e invocare metodi su oggetti remoti (oggetti che risiedono in uno spazio di memoria non locale ). L'invocazione di un metodo su un oggetto remoto è nota come chiamata del metodo remoto ( RMI ) o chiamata remota ed è l' analogo della programmazione orientata agli oggetti di una chiamata di procedura remota (RPC).

Mozziconi e scheletri di classe

L'approccio ampiamente utilizzato su come implementare il canale di comunicazione è realizzato utilizzando stub e scheletri . Sono oggetti generati la cui struttura e comportamento dipendono dal protocollo di comunicazione scelto, ma in generale forniscono funzionalità aggiuntive che garantiscono una comunicazione affidabile sulla rete.

In RMI, uno stub (che è il bit sul client) è definito dal programmatore come interfaccia . L'rmic (compilatore rmi) lo usa per creare lo stub della classe. Lo stub esegue il controllo del tipo. Lo scheletro è definito in una classe che implementa lo stub dell'interfaccia.

Oggetto distribuito communication.png

Quando un chiamante vuole eseguire una chiamata remota sull'oggetto chiamato, delega le richieste al suo stub che avvia la comunicazione con lo scheletro remoto . Di conseguenza, lo stub passa gli argomenti del chiamante sulla rete allo scheletro del server. Lo scheletro passa quindi i dati ricevuti all'oggetto chiamato, attende una risposta e restituisce il risultato allo stub del client. Notare che non c'è comunicazione diretta tra il chiamante e l'oggetto chiamato.

Più in dettaglio, la comunicazione si compone di diversi passaggi:

  1. chiamante chiama una procedura locale implementata dallo stub
  2. stub marshall chiama il tipo e gli argomenti di input in un messaggio di richiesta
  3. stub client invia il messaggio in rete al server e blocca il thread di esecuzione corrente
  4. lo scheletro del server riceve il messaggio di richiesta dalla rete
  5. scheletro decomprime il tipo di chiamata dal messaggio di richiesta e cerca la procedura sull'oggetto chiamato
  6. gli argomenti della procedura di unmarshall dello scheletro
  7. scheletro esegue la procedura sull'oggetto chiamato
  8. oggetto chiamato esegue un calcolo e restituisce il risultato
  9. scheletro racchiude gli argomenti di output in un messaggio di risposta
  10. scheletro invia il messaggio attraverso la rete al client
  11. stub client riceve il messaggio di risposta dalla rete
  12. stub decomprime gli argomenti di output dal messaggio
  13. stub passa argomenti di output al chiamante, rilascia il thread di esecuzione e il chiamante, quindi continua nell'esecuzione

Il vantaggio di questa architettura è che né il chiamante né l'oggetto chiamato devono implementare la logica relativa alla rete. Questa funzionalità, che garantisce un canale di comunicazione affidabile sulla rete, è stata spostata nello stub e nello scheletro .

Stub

L'oggetto lato client che partecipa alla comunicazione di oggetti distribuiti è noto come stub o proxy ed è un esempio di oggetto proxy .

Lo stub funge da gateway per gli oggetti lato client e tutte le richieste in uscita agli oggetti lato server che vengono instradati attraverso di esso. Lo stub avvolge la funzionalità dell'oggetto client e aggiungendo la logica di rete garantisce il canale di comunicazione affidabile tra client e server. Lo stub può essere scritto manualmente o generato automaticamente a seconda del protocollo di comunicazione scelto.

Lo stub è responsabile di:

  • iniziando la comunicazione verso lo scheletro del server
  • tradurre le chiamate dall'oggetto chiamante
  • smistamento dei parametri
  • informando lo scheletro che la chiamata dovrebbe essere invocata
  • passare argomenti allo scheletro attraverso la rete
  • smistamento della risposta dallo scheletro
  • informare il chiamante che la chiamata è terminata

Scheletro

L'oggetto lato server che partecipa alla comunicazione di oggetti distribuiti è noto come scheletro (o stub; termine evitato qui).

Uno scheletro funge da gateway per gli oggetti lato server e tutte le richieste dei client in entrata vengono instradate attraverso di esso. Lo scheletro avvolge la funzionalità dell'oggetto server e la espone ai client, inoltre aggiungendo la logica di rete garantisce il canale di comunicazione affidabile tra client e server. Gli scheletri possono essere scritti manualmente o generati automaticamente a seconda del protocollo di comunicazione scelto.

Lo scheletro è responsabile di:

  • traducendo i dati in arrivo dallo stub alle corrette chiamate verso gli oggetti del server
  • smistamento degli argomenti dai dati ricevuti
  • passare argomenti agli oggetti del server
  • marshalling dei valori restituiti dagli oggetti del server
  • passare i valori allo stub del client attraverso la rete

Protocolli che utilizzano un approccio stub/scheletro

Guarda anche

Riferimenti