Newsgroup: it.comp.lang.c++
Titolo: Filosofia socket...

Premetto che le socket le ho studiate, ma non usate.
A quanto mi ricordo, servono per spedire stream di dati
sul protocollo TCP o UDP.
Ma se io dovessi far comunicare due programmi residenti
su macchine diverse, volendo accedere alle istenze delle classi
residenti sull'altra macchina, come dovrei comportarmi?
Dovrei serializzare?
Cioe` trasferire byte a byte ogni membro della classe e
ricostruire tutto dall'altra parte?
E per i metodi?
Se cosi` fosse non e` un lavoraccio?
Non esiste qualche cosa a livello piu` alto?
Magari che non sia DCOM (come facevano 5 anni fa)?
Ciao e scusate per la FAQ a meta`.
Michele.

...


Magari che non sia DCOM (come facevano 5 anni fa)?
Chi faceva DCOM 5 anni fa?  Neppure dentro la
Microsoft...!
Comunque, le molteplici scelte comprendono, appunto:
DCOM; CORBA (quello, si`, che c'era 5 anni fa, e
anche prima!); IIOP (il protocollo di marshaling su cui
CORBA appoggia i suoi protocolli superiori); ILU (che
credo nelle versioni recenti possa usare IIOP, mentre
in precedenza usava un altro protocollo proprietario);
vari approcci di serializzazione e invocazione remota,
non standardizzati, ma spesso ispirati a quelli di Java
(Rogue Wave, mi pare, vende una libreria di classi che
dovrebbe appunto permettere interoperabilita` in rete
Java/C++; ObjectSpace, se non sbaglio, ha un altro
paio di simili librerie).
La maggior parte di queste possibilita` richiedono di
sborsare un tot di baiocchi per farne uso.  Le due
principali alternative gratis sono: DCOM, se devi restare
fra sistemi Win32 (so per sentito dire che esistono
versioni anche Unix, ma non so chi le distribuisca e
se siano gratuite); ILU, che, invece, forse e` ora
compatibile sia con vari sistemi Unix, Linux, BSD,
ecc, sia, anche, con Win32 (dovrai verificare cosa
combinino i suoi attuali release).
DCOM "nudo e crudo" e` scalabile solo sino ad un
certo punto: non lo consiglierei al di fuori di una rete
locale, o poche reti locali interconnesse da buoni
switches a discreta velocita` (non sotto il megabit
al secondo, non oltre le decine di millisecondi di
ritardo tipico); e non lo consiglierei oltre qualche
decina, *massimo* poche centinaia di sistemi in
comunicazione reciproca -- al di sopra di questi
livelli, bisogna cominciare a pensare a integrarlo
con la MSMQ e/o MTS.  ILU, l'ultima volta che ci
ho guardato (un paio d'anni fa), poteva essere
scalato con parametri non migliori di questi; altre
versioni Corba, commerciali, dovrebbero poter
fare di meglio (integrando, in pratica, una parte
di funzionalita` equivalenti a quelle di MSMQ/MTS,
e permettendo quindi una scalabilita` sino ad un
punto discreto [niente transazionale distribuito,
pero` -- almeno, non sino ad ora]).
Per questo tipo di considerazioni strategiche, e`
interessante il sito di Roger Sessions,
http://www.objectwatch.com
; Roger, un tempo
architetto dei servizi di persistenza di Corba, si
e` fatto molti nemici di recente proclamando che
l'architettura middleware Microsoft (COM e DCOM,
inevitabilmente integrati con MSMQ e MTS) e` oggi
tecnicamente superiore alle alternative (Corba,
Java [RMI, EJB, ...], ecc) -- al giorno d'oggi, tanto
e` l'astio diffuso contro Microsoft, qualsiasi
valutazione tecnica che risulti favorevole a MS
si tira spesso dietro simili "contraccolpi".
Alex

 E per i metodi?
Tutto dipende da cosa e come i due programmi devono comunicare. Se
effettivamente c'e` l'esigenza di condividere degli oggetti, allora penso che la
cosa migliore sia usare oggetti distribuiti (CORBA o DCOM). Se invece la
comunicazione fosse abbastanza semplice da poter essere agevolmente incanalata a
basso livello sui socket, potrebbe essere piu` conveniente implementare un
semplice protocollo di comunicazione ad hoc.
Saluti
Paolo


C'e' una sola risposta: CORBA!
