Newsgroup: it.comp.programmare.win32
Titolo: server COM out-of-process

sto realizzando due programmi che comunicano tra di loro (sulla stessa
macchina) chiamando attraverso apartments diversi metodi di oggetti COM;
il punto però è che di server COM ce ne dovrebbe essere uno solo
(requisito essenziale: il server contiene un oggetto che deve essere
"globale", deve essere chiamato da tutti) mentre di clients ce ne sono
sicuramente più d'uno.
per realizzare un'architettura simile ho impostato le cose nella seguente
maniera: sia il client che il server sono apartment-threaded; il server
implementa due classi: quella dell'oggetto globale più un'altra che funge
da "provider", ovvero contiene solo un metodo che restituisce un puntatore
all'oggetto globale. il server è registrato nella chiave CLSID col GUID
della classe "provider", percui quando un client chiama CoCreateInstance
richiedendo tale GUID il server parte, crea l'oggetto globale, riceve la
richiesta di istanziare una factory per produrre un provider, il client
riceve il provider e da esso ottiene l'oggetto globale.
o almeno questo è come dovrebbe funzionare nella mia testa, e sicuramente
sbaglio qualcosa perché in realtà come risultato ottengo che ciascun
client provoca l'avvio di un proprio server: N clients lanciano N servers
con N oggetti "globali"; nonostante io, nel registrare la factory del
server, abbia specificato CLSCTX_LOCAL_SERVER e REGCLS_MULTIPLEUSE.
cos'è che sbaglio? forse il threading model del server? il fatto che sia
single-apartment non dovrebbe far si' che la coda di messaggi serializzi
automaticamente le chiamate concorrenti ai metodi?
un ringraziamento anticipato per qualunque aiuto :)
saluti
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 cos'è che sbaglio? 
a mio parere, sbagli il tipo di tecnologia che stai tentando di utilizzare.
La possibilità che ti dà COM (o DCOM in questo caso) di scambiarsi dati 
out-of-process tramite oggetti è bello ma ha troppe controindicazioni: 
permessi da settare per gli utenti per poter lanciare il processo 
remoto, utilizzo del registro, conflitti tra versioni diverse degli 
oggetti, ecc.
Tant'è che anche la stessa Microsoft ha abbandonato la tecnologia COM 
con .NET.
In base alla mia esperienza, la soluzione ideale per la comunicazione 
tra processi è tramite socket: è più leggero, non si basa sun una 
tecnologia "oscura", è portabile anche su altri sistemi operativi, ecc.
ciao

 è portabile anche su altri sistemi operativi, ecc.
nessun problema: il programma che sto scrivendo ha come target
esclusivamente Windows. comunque anche COM è cross-platform: mi pare che
Firefox ne usi un'implementazione opensource.


 il punto però è che di server COM ce ne dovrebbe essere uno solo
guarda,
in teoria dovrebbe andare.
Ho scritto un server giocattolo con ATL e funziona esattamente come 
vorresti tu.
Prova anche tu a farti una coppia client/server giocattolo e vedi se 
funziona. Coi wizard e il resto servono 10 minuti.
(io di solito faccio un server minimo con ATL e i wizard, e un client 
minimale con un dialog MFC che invoca il server quando clicko un bottone)
GM