Domanda di progettazione: come posso accedere in modo trasparente a un meccanismo IPC?

Question

Voglio fare questo (nessuna lingua particolare):

print(foo.objects.bookdb.books[12].title);

o questo:

book = foo.objects.bookdb.book.new();
book.title = 'RPC for Dummies';
book.save();

Laddove Foo è in realtà un servizio collegato al mio programma tramite alcuni IPC e per accedere ai suoi metodi e oggetti, alcuni layer in realtà inviano e ricevono messaggi sulla rete.

Ora, non sto davvero cercando un meccanismo IPC, poiché ci sono molte tra cui scegliere. È probabile che non sia basato su XML, ma piuttosto su s. esimo. come i buffer di protocollo di Google, dbus o CORBA. Ciò di cui non sono sicuro è come strutturare l'applicazione in modo da poter accedere all'IPC proprio come farei qualsiasi oggetto.

In altre parole, come posso avere OOP che mappa in modo trasparente oltre i limiti del processo?

Non che questa sia una domanda di progettazione e sto ancora lavorando a un livello piuttosto alto dell'architettura generale. Quindi sono abbastanza agnostico riguardo alla lingua in cui si troverà. C #, Java e Python probabilmente si abitueranno comunque.

Answer 1

Non dovresti farlo! È molto importante per i programmatori vedere e percepire la differenza tra un IPC / RPC e una chiamata di metodo locale nel codice. Se lo fai in modo che non debbano pensarci, non ci penseranno e questo porterà a un codice molto scarso.

Pensa a:

foreach o, o.isGreen in someList { 
   o.makeBlue; 
}

Il programmatore presume che il completamento dei loop richieda alcuni nanosecondi, invece ci vuole quasi un secondo se qualche elenco risulta essere remoto.

Answer 2

Penso che il modo per fare ciò che stai richiedendo sia di considerare tutte le comunicazioni degli oggetti come passaggio di messaggi. Questo è il modo in cui vengono gestiti i metodi oggetto in ruby ??e smalltalk, tra gli altri.

Con il passaggio del messaggio (anziché la chiamata del metodo) come meccanismo di comunicazione dell'oggetto, quindi operazioni come la chiamata di un metodo che non esisteva quando si scriveva il codice diventano sensate poiché l'oggetto può comunque fare qualcosa di sensato con il messaggio (controllare per una procedura remota, restituisci un valore per un campo con lo stesso nome da un database, ecc. oppure genera un'eccezione "metodo non trovato" o qualsiasi altra cosa ti venga in mente).

È importante notare che per le lingue che non lo usano come meccanismo predefinito, puoi comunque fare passare i messaggi (ogni oggetto ha un metodo 'handleMessage') ma non otterrai le caratteristiche di sintassi e hai vinto non sarai in grado di ottenere aiuto IDE senza alcuno sforzo aggiuntivo da parte tua per ottenere l'IDE per analizzare il tuo metodo handleMessage per verificare input validi.

Answer 3

Leggi su RMI di Java - l'introduzione materiale mostra come è possibile avere una definizione locale di un oggetto remoto.

Il trucco è avere due classi con firme di metodo identiche. La versione locale della classe è una facciata su alcuni protocolli di rete. La versione remota riceve richieste sulla rete e svolge il lavoro effettivo dell'oggetto.

Puoi definire una coppia di classi in modo che un client possa avere

foo= NonLocalFoo( "http://host:port" )
foo.this= "that"
foo.save()

E il server riceve le richieste del metodo set_this () e save () da una connessione client. Il lato server è (generalmente) non banale perché hai un sacco di problemi di rilevazione e gestione delle istanze.