DCOM, Installazione e comportamento
Zanna
informazioni.
Sto realizzando un progetto di un componente che risiederà su un server
(ActiveX-EXE) e che deve essere richiamato da vari client.
1) Ho bisogno che questo oggetto gestisca in modo sincrono e come "FIFO" le
richieste dei vari client (cioè voglio sia che l'ordine temporale
d'esecuzione delle chiamate rimanga quello di come sono state fatte, sia che
se sto eseguendo la chiamata del client A quella del client B resta in
attesa del suo turno).
Per fare questo basta settagli il Pool di trheading a 1 solo thread?
2) Qual è il modo più semplice di installazione sia sui client che sul
server?
Devo giocare con la voce "servizi componenti" del pannello di controllo?
(non mi è nemmeno molto chiara la differenza tra COM+ DCOM e MTS...)
3) E' possibile per l'ActiveX-exe conoscere il nome del client che ha
effettuato la chiamata?
Ciao, grazie.
--
Math Parser : http://www.neodatatype.net
Sito Comune : http://www.it-lang-vb.net
Fox Mulder
"Zanna" <znt....@virgilio.it> ha scritto nel messaggio
news:QrAbc.14522$rM4.6...@news4.tin.it...
> A chi ha affrontato il problema DCOM, vorrei chiedere un paio di
> informazioni.
>
> Sto realizzando un progetto di un componente che risiederà su un server
> (ActiveX-EXE) e che deve essere richiamato da vari client.
>
> 1) Ho bisogno che questo oggetto gestisca in modo sincrono e come "FIFO"
le
> richieste dei vari client (cioè voglio sia che l'ordine temporale
> d'esecuzione delle chiamate rimanga quello di come sono state fatte, sia
che
> se sto eseguendo la chiamata del client A quella del client B resta in
> attesa del suo turno).
> Per fare questo basta settagli il Pool di trheading a 1 solo thread?
modo tale che i client sfruttino lo stesso codice (o spazio di programma) in
esecuzione.
Comunque la strada è giusta.
> 2) Qual è il modo più semplice di installazione sia sui client che sul
> server?
Se ne era discusso circa un paio di mesi fa ed alla fine i metodi migliori
sono risultati :
A] - creare 2 progetti : 1 client e 1 server; installare entrabi sui client
ed una sola volta il progetto server sul server DCOM; configurare
manualmente il dcom sia sui client che sul server (con dcomcnfg.exe) in modo
tale che l'esecuzione rimanga sempre sul server DCOM.
B] - creare sempre i 2 progetti separati; il progetto server deve essere
generato creando il "file per esecuzione remota"; quindi sul client lanciare
il clireg32.exe (si trova nelle cartelle di visual studio) che registrerà il
DCOM
Non entro troppo nei dettagli ora.
> Devo giocare con la voce "servizi componenti" del pannello di controllo?
> (non mi è nemmeno molto chiara la differenza tra COM+ DCOM e MTS...)
COM+ è l'insieme delle tecnologie per la gestione degli oggetti COM e
oggetti transazionali distribuiti tramite un web server (per cui se hai una
rete LAN e basta, non ti conviene anche perchè un po' difficile da
configurare).
MTS è il gestore dello stato delle transazioni degli oggetti ... in 2000 si
chiama Component service ... MTS è il nome per NT
DCOM non è nient'altro che un servizio che replica le chiamate COM di un
oggetto su una macchina remota (dato che COM è concepito per essere eseguito
solo in locale)... è un po' il concetto dei servizi "server" e "workstation"
che vedi sulle macchine 2000/NT.
> 3) E' possibile per l'ActiveX-exe conoscere il nome del client che ha
> effettuato la chiamata?
Penso che in modo semplice, no.
Però puoi imporre tutte le limitazioni di esecuzione del componente
attraverso il configuratore DCOM .. altrimenti chiunque della lan potrebbe
istanziare i tuoi oggetti DCOM, e questo non è bello.
Se vuoi sapere il nome della macchina chiamante o dell'utente ecc.. puoi
creare un metodo di login (anche se da codice server non puoi impedire che
venga creata l'istanza dell'oggetto di login e neanche la puoi abbattere).
Se ti serve altro nello specifico chiedi pure.
Saluti
Zanna
>>Per fare questo basta settagli il Pool di trheading a 1 solo thread?
>
> Questo tipo di impostazione ti permette di condividere la stessa istanza in
> modo tale che i client sfruttino lo stesso codice (o spazio di programma) in
> esecuzione.
> Comunque la strada è giusta.
... la strada è giusta significa che c'è altro dietro da considerare o
fa proprio così?
>>2) Qual è il modo più semplice di installazione sia sui client che sul
>>server?
>
> Se ne era discusso circa un paio di mesi fa ed alla fine i metodi migliori
> sono risultati :
Allora adesso provo a cercare
> A] - creare 2 progetti : 1 client e 1 server; installare entrabi sui client
> ed una sola volta il progetto server sul server DCOM; configurare
> manualmente il dcom sia sui client che sul server (con dcomcnfg.exe) in modo
> tale che l'esecuzione rimanga sempre sul server DCOM.
non ho capito perchè installare il server sul client.
E per installare intendi registrare?
> B] - creare sempre i 2 progetti separati; il progetto server deve essere
> generato creando il "file per esecuzione remota"; quindi sul client lanciare
> il clireg32.exe (si trova nelle cartelle di visual studio) che registrerà il
> DCOM
Forse questa è la soluzione più semplice.
>>3) E' possibile per l'ActiveX-exe conoscere il nome del client che ha
>>effettuato la chiamata?
>
> Penso che in modo semplice, no.
> Però puoi imporre tutte le limitazioni di esecuzione del componente
> attraverso il configuratore DCOM .. altrimenti chiunque della lan potrebbe
> istanziare i tuoi oggetti DCOM, e questo non è bello.
Non è tanto per la sicurezza, quanto per poter fare un log di chi fa
cosa, anche per poter risolvere eventuali problemi.
Avevo pensato a un metodo tipo Login, ma poi, essendo il processo unico,
non posso comunque sapere chi sta chiamando in quel momento, ma solo
avere la lista dei connessi.
Ciao
Fox Mulder
> Fox Mulder wrote:
>
>
> >>Per fare questo basta settagli il Pool di trheading a 1 solo thread?
> >
> > Questo tipo di impostazione ti permette di condividere la stessa istanza
in
> > modo tale che i client sfruttino lo stesso codice (o spazio di
programma) in
> > esecuzione.
> > Comunque la strada è giusta.
>
> ... la strada è giusta significa che c'è altro dietro da considerare o
> fa proprio così?
Nel senso che io non ne conosco altre e che a me, così, funziona :)
> >>2) Qual è il modo più semplice di installazione sia sui client che sul
> >>server?
> >
> > Se ne era discusso circa un paio di mesi fa ed alla fine i metodi
migliori
> > sono risultati :
>
> Allora adesso provo a cercare
>
> > A] - creare 2 progetti : 1 client e 1 server; installare entrabi sui
client
> > ed una sola volta il progetto server sul server DCOM; configurare
> > manualmente il dcom sia sui client che sul server (con dcomcnfg.exe) in
modo
> > tale che l'esecuzione rimanga sempre sul server DCOM.
>
> non ho capito perchè installare il server sul client.
> E per installare intendi registrare?
Nel pacchetto di installazione del client deve esserci anche l'exe AX (la
stessa versione installata sul server).
Le chiamate di un metodo sono sempre locali; è il DCOM che - opportunamente
configurato - si preoccupa di inoltrarle al server e lì, farle eseguire; in
teoria servirebbe soltanto la type library di tutte le classi esposte, in
pratica devi avere tutto il componente anche sul client.
Sono necessari 2 pacchetti di installazione diverse (quella del prg client e
quella del componente server) in quanto se devi aggiornare il prog. client
andresti a rimuovere anche il server
>
> > B] - creare sempre i 2 progetti separati; il progetto server deve essere
> > generato creando il "file per esecuzione remota"; quindi sul client
lanciare
> > il clireg32.exe (si trova nelle cartelle di visual studio) che
registrerà il
> > DCOM
>
> Forse questa è la soluzione più semplice.
>
>
> >>3) E' possibile per l'ActiveX-exe conoscere il nome del client che ha
> >>effettuato la chiamata?
> >
> > Penso che in modo semplice, no.
> > Però puoi imporre tutte le limitazioni di esecuzione del componente
> > attraverso il configuratore DCOM .. altrimenti chiunque della lan
potrebbe
> > istanziare i tuoi oggetti DCOM, e questo non è bello.
>
> Non è tanto per la sicurezza, quanto per poter fare un log di chi fa
> cosa, anche per poter risolvere eventuali problemi.
>
> Avevo pensato a un metodo tipo Login, ma poi, essendo il processo unico,
> non posso comunque sapere chi sta chiamando in quel momento, ma solo
> avere la lista dei connessi.
Il processo è unico ma non lo sono le istanze client; ogni New è una nuova
istanza sul server
Saluti
Zanna
> Nel pacchetto di installazione del client deve esserci anche l'exe AX (la
> stessa versione installata sul server).
> Le chiamate di un metodo sono sempre locali; è il DCOM che - opportunamente
> configurato - si preoccupa di inoltrarle al server e lì, farle eseguire; in
> teoria servirebbe soltanto la type library di tutte le classi esposte, in
> pratica devi avere tutto il componente anche sul client.
Infatti stavo provando a referenziare la TLB che crea VB, ma mi dice che
il componente non è registrato sul client (???) e infatti le classi non
sono presenti nel registro (!!!).
Ora sto provando con l'ax-exe registrato ma mi da un bel 70
Autorizzazione Negata... che centrino i permessi?
Ma cosa cavolo devo toccare ora?
> Il processo è unico ma non lo sono le istanze client; ogni New è una nuova
> istanza sul server
Ummmm... infatti questa era una prova che stavo per fare.
Solo che così si mantiene il sincronismo del punto 1?
In teoria sì, essendo a singolo thread... spero :)
Ciao
Fox Mulder
> Fox Mulder wrote:
>
>
> > Nel pacchetto di installazione del client deve esserci anche l'exe AX
(la
> > stessa versione installata sul server).
> > Le chiamate di un metodo sono sempre locali; è il DCOM che -
opportunamente
> > configurato - si preoccupa di inoltrarle al server e lì, farle eseguire;
in
> > teoria servirebbe soltanto la type library di tutte le classi esposte,
in
> > pratica devi avere tutto il componente anche sul client.
>
> Infatti stavo provando a referenziare la TLB che crea VB, ma mi dice che
> il componente non è registrato sul client (???) e infatti le classi non
> sono presenti nel registro (!!!).
>
> Ora sto provando con l'ax-exe registrato ma mi da un bel 70
> Autorizzazione Negata... che centrino i permessi?
> Ma cosa cavolo devo toccare ora?
Ma referenzi l'oggetto sul client o sul server ? immagino sul client.
vai nel dcomcnfg.exe, seleziona la tua classe - properties -
scheda Generale : livello autentificazione = Nessuno
scheda Percorso : spunta l'ultima voce "Esegui l'appli sul seguente PC:" e
scrivi il nome della macchina server
Identità : Utente che esegue l'appli
Endpoint : assicurati di avere il TCP/Ip
Protezione : dovresti lasciare tutto di default
>
> > Il processo è unico ma non lo sono le istanze client; ogni New è una
nuova
> > istanza sul server
>
> Ummmm... infatti questa era una prova che stavo per fare.
> Solo che così si mantiene il sincronismo del punto 1?
> In teoria sì, essendo a singolo thread... spero :)
Penso che sia imprevedibile .. cioè se il client A esegue un metodo server e
subito dopo (distanza di 1 secondo) il client B esegue lo stesso metodo,
credo che non ci siano garanzie sul fatto che il metodo venga eseguito con
lo stesso ordine di chiamata, anche perchè le condizioni dipendono anche da
fattori esterni quali : stato della rete, tipologia di connessione, stato
del sistema in generale ecc..
Comunque in .net il dcom è stato sostituito da una tecnologia migliore,
nativa nel framework, ma non ricordo il nome.
Saluti
Zanna
> Ma referenzi l'oggetto sul client o sul server ? immagino sul client.
Allora... ho seguito questo:
http://support.microsoft.com/default.aspx?kbid=266717
Ora ho installato il componente sia sul client che sul server.
Adesso ottengo un
errore 642:
oppure se specifico il server nella createobject
-2147024770 (non documentato)
Errore di automazione
Impossibile trovare il modulo specificato
Sembra che non riesca a settare correttamente i permessi.
> vai nel dcomcnfg.exe, seleziona la tua classe - properties -
> scheda Generale : livello autentificazione = Nessuno
> scheda Percorso : spunta l'ultima voce "Esegui l'appli sul seguente PC:" e
> scrivi il nome della macchina server
> Identità : Utente che esegue l'appli
> Endpoint : assicurati di avere il TCP/Ip
> Protezione : dovresti lasciare tutto di default
Ok, ora ho impostato il client in questo modo, e l'errore che ottengo è
sempre quello di automazione sopraindicato.
Comunque non è pensabile per me andare su ogni client e configurarlo a
mano...
>>Solo che così si mantiene il sincronismo del punto 1?
>>In teoria sì, essendo a singolo thread... spero :)
>
>
> Penso che sia imprevedibile .. cioè se il client A esegue un metodo server e
> subito dopo (distanza di 1 secondo) il client B esegue lo stesso metodo,
> credo che non ci siano garanzie sul fatto che il metodo venga eseguito con
> lo stesso ordine di chiamata, anche perchè le condizioni dipendono anche da
> fattori esterni quali : stato della rete, tipologia di connessione, stato
> del sistema in generale ecc..
Sì, certo.
In effetti ripensandoci questa "FIFO" temporale non mi interessa,
l'importante è che venga eseguita solo una alla volta.
> Comunque in .net il dcom è stato sostituito da una tecnologia migliore,
> nativa nel framework, ma non ricordo il nome.
Può darsi, ma io lo devo fare per VB :)
Ciao
Fox Mulder
> Fox Mulder wrote:
>
>
> > Ma referenzi l'oggetto sul client o sul server ? immagino sul client.
>
> Allora... ho seguito questo:
> http://support.microsoft.com/default.aspx?kbid=266717
>
> Ora ho installato il componente sia sul client che sul server.
> Adesso ottengo un
>
> errore 642:
>
> oppure se specifico il server nella createobject
>
> -2147024770 (non documentato)
> Errore di automazione
> Impossibile trovare il modulo specificato
>
> Sembra che non riesca a settare correttamente i permessi.
>
> > vai nel dcomcnfg.exe, seleziona la tua classe - properties -
> > scheda Generale : livello autentificazione = Nessuno
> > scheda Percorso : spunta l'ultima voce "Esegui l'appli sul seguente PC:"
e
> > scrivi il nome della macchina server
> > Identità : Utente che esegue l'appli
> > Endpoint : assicurati di avere il TCP/Ip
> > Protezione : dovresti lasciare tutto di default
>
> Ok, ora ho impostato il client in questo modo, e l'errore che ottengo è
> sempre quello di automazione sopraindicato.
>
> Comunque non è pensabile per me andare su ogni client e configurarlo a
> mano...
dimenticavo .. hai registrato il componente sul server ?
nome_componente.exe /REGSERVER
anche sul server devi configurare le classi con il DCOMcnfg.exe
vai nel dcomcnfg.exe, seleziona la tua classe - properties -
su protezione, assicurati che per ognuno dei 3 tipi di permesso sia incluso
SYSTEM e la macchina server;
il server alza eventi sul client ?
Saluti
Zanna
> dimenticavo .. hai registrato il componente sul server ?
>
> nome_componente.exe /REGSERVER
;) Certo che sì.
> anche sul server devi configurare le classi con il DCOMcnfg.exe
> vai nel dcomcnfg.exe, seleziona la tua classe - properties -
> su protezione, assicurati che per ognuno dei 3 tipi di permesso sia incluso
> SYSTEM e la macchina server;
...se intendi quello di avvio, esecuzione e configurazione ho aggiunto a
tutti Everyone, ma non c'è verso di farlo funzionare.
Mi da errore: Impossibile trovare il modulo specificato
al momento della CreateObject()... sembra che non veda le classi del
componente, che eppure è stato registrato con clireg32.exe :(
E anche 'sto clireg32 non è molto documentato, ad es. non ho capito se
serve o no indicare il protocollo e come indicarlo, dato che quando
registro l'Ax come DCOM il combo del protocollo è disabilitato...
> il server alza eventi sul client ?
Per ora no, ma in futuro non si sa.
Comunque la cosa stana è questa: nell'elenco delle APP DCOM registrate
vedo una classe del mio componente, e non capisco in base a cosa abbia
scelto quella da elencare anziche altre...
ora il server è un PC con winXP e il configuratore è leggermente diverso
da quello di win9x e 2000.
Ciao, grazie
Fox Mulder
> Fox Mulder wrote:
> al momento della CreateObject()... sembra che non veda le classi del
> componente, che eppure è stato registrato con clireg32.exe :(
> E anche 'sto clireg32 non è molto documentato, ad es. non ho capito se
> serve o no indicare il protocollo e come indicarlo, dato che quando
> registro l'Ax come DCOM il combo del protocollo è disabilitato...
> Comunque la cosa stana è questa: nell'elenco delle APP DCOM registrate
> vedo una classe del mio componente, e non capisco in base a cosa abbia
> scelto quella da elencare anziche altre...
> ora il server è un PC con winXP e il configuratore è leggermente diverso
> da quello di win9x e 2000.
si, il clireg lo trovo un po' strano anch'io .. è per questo che uso il
dcomcnfg manualmente (ho 20 macchine max).
in realtà non ho mai provatato ad utilizzare una macchina client come server
dcom.
A questo punto mi viene in mente solo che il firewall di xp blocchi per
default dcom (o il firewall della lan);
oppure hai la possibilità di usare macchine 2000 per delle prove ?
E' vero che la createobject() ti consente di specificare su quale macchina
eseguire l'oggetto e che non ti devi preoccupare delle compatibilità ma,
secondo me, è conveniente sfruttare le funzionalità dell'early binding; se
poi dovrai generare eventi sul client, ti perdi la possibilità di dichiarare
col withevents e ripiegare sulle funzioni di callback (che funzionano anche
meglio degli eventi ma che non sono di certo il modo più lineare per
programmare).
Saluti
PS : quando circa 3 anni fa mi sono approcciato a DCOM, dopo una settimana
di tentativi ho scritto a Francesco Balena in persona, il quale mi ha
risposto (veramente a tempo di record) dandomi i link diretti ai siti MS
(quelli che tu hai già).
Direi che è stato alquanto gentile.
Zanna
> in realtà non ho mai provatato ad utilizzare una macchina client come server
> dcom.
Ho già visto un piccolo DCOM girare su un PC WinXP pro...
> A questo punto mi viene in mente solo che il firewall di xp blocchi per
> default dcom (o il firewall della lan);
Ecco, il FW di XP... non ho mai capito come si abilita/disabilita, anche
se non credo sia abilitato.
Quello della lan non funziona solo verso l'esterno?
> oppure hai la possibilità di usare macchine 2000 per delle prove ?
Sì, era quello che volevo provare oggi.
> E' vero che la createobject() ti consente di specificare su quale macchina
> eseguire l'oggetto e che non ti devi preoccupare delle compatibilità ma,
> secondo me, è conveniente sfruttare le funzionalità dell'early binding; s
Sì, includendo la type lib.
Prima però volevo farlo funzionare :)
> poi dovrai generare eventi sul client, ti perdi la possibilità di dichiarare
> col withevents e ripiegare sulle funzioni di callback (che funzionano anche
> meglio degli eventi ma che non sono di certo il modo più lineare per
> programmare).
Perchè, cosa cambia se dovessi generare eventi?
> PS : quando circa 3 anni fa mi sono approcciato a DCOM, dopo una settimana
> di tentativi ho scritto a Francesco Balena in persona, il quale mi ha
> risposto (veramente a tempo di record) dandomi i link diretti ai siti MS
> (quelli che tu hai già).
> Direi che è stato alquanto gentile.
Peccato che il DCOMCnfg per win fino al 2000 (quello descritto in questi
doc) sia diverso da quello di XP... che comunque mi pare di aver provato
in tutte le salse.
Ciao, grazie ancora.
Fox Mulder
CUT
> Quello della lan non funziona solo verso l'esterno?
da switch, firewall e router e controlla il traffico anche dei singoli
pacchetti ethernet .. come solo uno switch store&forward potrebbe farti da
firewall, sniffer, logger ecc.. io l'ho solo buttata lì come idea .. si sa
mai
> > poi dovrai generare eventi sul client, ti perdi la possibilità di
dichiarare
> > col withevents e ripiegare sulle funzioni di callback (che funzionano
anche
> > meglio degli eventi ma che non sono di certo il modo più lineare per
> > programmare).
>
> Perchè, cosa cambia se dovessi generare eventi?
In pratica devi dare i permessi all'oggetto DCOM installato sul client di
eseguire funzioni generate dal server (è per questo che bisogna annullare il
livello di identificazione)
Saluti
Zanna
Allora, credo di aver trovato... e non ho parole, solo parolaccie!
Ho provato a fare un progetto da zero aggiungendo a mano a mano le
classi che mi servivano... e tutto continuava a funzionare...
Ho controllato tutti i flag del progetto...
Sono arrivato a questo sconvolgente risultato: se metto la descizione
del progetto mi da un costante errore 70: accesso negato.
Senza la descrizione del progetto tutto funziona usando la
CreateObject(classe, server) (anche se ho usato il clireg32... boh).
Per fortuna posso comunque usare la .tlb tra i riferimenti cosě posso fare:
Dim x as myclass
Set x = CreateObject("prj.myclass", server)
e sfruttare l'intellisense.
Se uso la
Set x = New MyClass
o la CreateObject senza server ottengo un errore di automazione
"impossibile trovare il modulo specificato".
Questo senza configurare niente sul client oltre al clireg32.
Inoltre sul server ho dovuto permettere l'accesso all'utente interattivo
poichč ho un form nel mio Ax-exe, altrimenti ancora errore 70.
Ora provo senza il clireg32 che a questo punto mi pare inutile.
Ciao