[COM] due domande

[71104]

in questo periodo ho molto approfondito le mie conoscenze a riguardo, e mi sono anche fatto sorgere dei dubbi. rivolgendomi a chi, sul forum, abbia una certa conoscenza di questa tecnologia, vorrei fare due domande:

1) quale cavolo è la differenza tra COM e OLE? :D
prima credevo di saperlo, ora dopo aver letto decine di pagine su MSDN non lo so più. di preciso vorrei sapere di quali specifici compiti si occupa COM e di quali OLE.

2) quali sono, allo stato attuale, i problemi (irrisolti/irrisolvibili/difficilmente risolvibili) e gli aspetti negativi di queste tecnologie?

tenchiu' for l'attenscion [cit.]

[okay]

in questo periodo ho molto approfondito le mie conoscenze a riguardo, e mi sono anche fatto sorgere dei dubbi. rivolgendomi a chi, sul forum, abbia una certa conoscenza di questa tecnologia, vorrei fare due domande:

1) quale cavolo è la differenza tra COM e OLE? :D
prima credevo di saperlo, ora dopo aver letto decine di pagine su MSDN non lo so più. di preciso vorrei sapere di quali specifici compiti si occupa COM e di quali OLE.

2) quali sono, allo stato attuale, i problemi (irrisolti/irrisolvibili/difficilmente risolvibili) e gli aspetti negativi di queste tecnologie?

tenchiu' for l'attenscion [cit.]


http://it.wikipedia.org/wiki/ActiveX

buon studio

[71104]

up :mc:

[71104]

up :sofico:

[tomminno]

in questo periodo ho molto approfondito le mie conoscenze a riguardo, e mi sono anche fatto sorgere dei dubbi. rivolgendomi a chi, sul forum, abbia una certa conoscenza di questa tecnologia, vorrei fare due domande:

1) quale cavolo è la differenza tra COM e OLE? :D
prima credevo di saperlo, ora dopo aver letto decine di pagine su MSDN non lo so più. di preciso vorrei sapere di quali specifici compiti si occupa COM e di quali OLE.


In questo periodo ho cominiciato ad approfondire anch'io l'argomento COM per trovare strani errori segnalati dal Microsoft Provisioning System.

Ho sempre pensato che COM fosse una evoluzione di OLE, invece poi ho realizzato che OLE è costruito sopra COM, solo che COM è stato divulgato successivamente. Insomma OLE è stata la prima implementazione di COM.

Che mi risulti (alle mie conoscenze attuali, visto che trovo parecchia confuzione in giro sull'argomento, sembra che neanche alla Microsoft abbiano chiare le differenze) COM è una specifica potenzialmente multipiattaforma (basta vedere XPCOM di Firefox che è praticamente identico a MS-COM), mentre OLE è una implementazione usata inizialmente per integrare "Excel in Word".


2) quali sono, allo stato attuale, i problemi (irrisolti/irrisolvibili/difficilmente risolvibili) e gli aspetti negativi di queste tecnologie?

tenchiu' for l'attenscion [cit.]

Direi (per quanto ho usato i COM) che interrogare una interfaccia per conoscere le interfacce supportate da un oggetto (:muro: ) è una vera bestialità, e per questo è stata inserita l'aggregazione.

Poi problemi di sicurezza che sono venuti fuori in passato grazie a DCOM.

Inoltre non era (è?) considerato valido per applicativi enterprise.
Io so solo che Exchange usato tramite un webserivce Microsoft che richiama oggetti COM di Exchange, ogni tanto necessita di riavvio della macchina (2 8 core con bilanciatore) perchè non si ripiglia più, comincia a dare errori random.

Poi diciamoci la verità il software vb che registrava COM a sfare sputtanava la macchina che era una meraviglia.

[tomminno]

Dimenticavo ci sono un sacco di problemi con il multithread

[71104]

Ho sempre pensato che COM fosse una evoluzione di OLE, io invece ho sempre pensato che COM fosse la piattaforma a oggetti (che si occupa di compiti fondamentali come interfacce, registrazione, marshaling, e threading models) e che OLE fosse un set di API e di interfacce per la gestione dei documenti composti; ciò però non mi torna perché nella documentazione MSDN a un certo punto, ma di punto in bianco, mi comincia a parlare di OLE in sezioni dove in teoria OLE ancora non è stato nemmeno introdotto :cry:

invece poi ho realizzato che OLE è costruito sopra COM, solo che COM è stato divulgato successivamente. Insomma OLE è stata la prima implementazione di COM.

Che mi risulti (alle mie conoscenze attuali, visto che trovo parecchia confuzione in giro sull'argomento, sembra che neanche alla Microsoft abbiano chiare le differenze) COM è una specifica potenzialmente multipiattaforma (basta vedere XPCOM di Firefox che è praticamente identico a MS-COM), mentre OLE è una implementazione usata inizialmente per integrare "Excel in Word". ciascuna di queste frasi sembra dirmi una cosa completamente diversa dalle altre :|
(a parte il fatto che siano confusi anche alla Microsoft: quella è l'unica frase che non contrasta con le altre :asd: )


Direi (per quanto ho usato i COM) che interrogare una interfaccia per conoscere le interfacce supportate da un oggetto (:muro: ) è una vera bestialità, spero che tutto il gran chiasso che si alza spesso su COM non sia dovuto esclusivamente a questioni di ingegneria del software :D

e per questo è stata inserita l'aggregazione. che io sappia l'aggregazione mira a scopi leggermente diversi e per nulla inerenti all'ingegneria del software: si tratta di un caso particolare della composizione. quando un oggetto deve esporre tale e quale un'interfaccia implementata da un oggetto contenuto esso non può restituirla direttamente dalla QueryInterface perché se poi da essa il chiamante effettuasse una query per ottenere IUnknown otterrebbe l'IUnknown dell'oggetto contenuto, il quale avrebbe un reference count diverso da quello del contenitore. per risolvere il problema l'oggetto contenuto deve delegare la sua IUnknown a quella del contenitore.

Poi problemi di sicurezza che sono venuti fuori in passato grazie a DCOM. tipo?

Inoltre non era (è?) considerato valido per applicativi enterprise.
Io so solo che Exchange usato tramite un webserivce Microsoft che richiama oggetti COM di Exchange, ogni tanto necessita di riavvio della macchina (2 8 core con bilanciatore) perchè non si ripiglia più, comincia a dare errori random. dunque potremmo mettere in lista dei bug nell'implementazione (che però non costituiscono un problema della specifica). ma sei sicuro che sia colpa di COM/OLE e non di Exchange?

Poi diciamoci la verità il software vb che registrava COM a sfare sputtanava la macchina che era una meraviglia. tipo?

Dimenticavo ci sono un sacco di problemi con il multithread tipo?

[fek]

in questo periodo ho molto approfondito le mie conoscenze a riguardo,

Ma non eri troppo impegnato per stare dietro a Diamonds? :D

[tomminno]

io invece ho sempre pensato che COM fosse la piattaforma a oggetti (che si occupa di compiti fondamentali come interfacce, registrazione, marshaling, e threading models) e che OLE fosse un set di API e di interfacce per la gestione dei documenti composti; ciò però non mi torna perché nella documentazione MSDN a un certo punto, ma di punto in bianco, mi comincia a parlare di OLE in sezioni dove in teoria OLE ancora non è stato nemmeno introdotto :cry:


Infatti, solo che per gestire documenti compositi usa COM :)


ciascuna di queste frasi sembra dirmi una cosa completamente diversa dalle altre :|
(a parte il fatto che siano confusi anche alla Microsoft: quella è l'unica frase che non contrasta con le altre :asd: )


Cosa c'è che non torna? COM è la tecnologia usata da OLE, solo che il nome COM viene fuori solo con OLE 2.0.


spero che tutto il gran chiasso che si alza spesso su COM non sia dovuto esclusivamente a questioni di ingegneria del software :D

che io sappia l'aggregazione mira a scopi leggermente diversi e per nulla inerenti all'ingegneria del software: si tratta di un caso particolare della composizione. quando un oggetto deve esporre tale e quale un'interfaccia implementata da un oggetto contenuto esso non può restituirla direttamente dalla QueryInterface perché se poi da essa il chiamante effettuasse una query per ottenere IUnknown otterrebbe l'IUnknown dell'oggetto contenuto, il quale avrebbe un reference count diverso da quello del contenitore. per risolvere il problema l'oggetto contenuto deve delegare la sua IUnknown a quella del contenitore.


Se un oggetto eredita da 2 interfacce devi usare l'aggregazione perchè QueryInterface viene eseguito su una interfaccia.
E siccome QueryInterface deve sempre ritornare tutte le interfacce supportate dall'oggetto, se non usi l'aggregazione non rispetti i requisiti di COM.


tipo?


Negli anni passati ci sono stati tanti aggiornamenti dedicati proprio a COM e DCOM per falle nell'implementazione del sistema. Su google trovi tutto.


dunque potremmo mettere in lista dei bug nell'implementazione (che però non costituiscono un problema della specifica). ma sei sicuro che sia colpa di COM/OLE e non di Exchange?


Magari non sarà colpa della specifica COM ma se non riescono a farla funzionare alla Microsoft, dove è stata creata, su un prodotto che costa un botto e che viene installato da gente proveniente direttamente dalla Microsoft e che viene consegnato praticamente a scatola chiusa...

Per fare un paragone se scrivo un software con memory leak in C++ è certamente colpa mia, non certo del C++, ma ci sono altri linguaggi che vengono incontro ai possibili errori dei programmatori.


tipo?


Tipo pacchetti di installazione che riscrivevano sopra oggetti COM preesistenti, e poi non funzionava più niente.


tipo?

Tipo che devi gestire te l'accesso multithread ad un oggetto COM perchè nessuno ti garantisce che sia threadsafe, anzi non sono praticamente mai threadsafe, un esempio è ADSI.

Adesso scappo che devo andare.