Componenti COM

Componenti COM (COM server) Un Componente COM implementa ed esporta un insieme di Interfacce (oltre a IUnknown) Limplementazione delle interfacce è fornita da un insieme di CoClass Ogni CoClass è univocamente identificata da un CLSID Le CoClass di un componente sono contenute nel file eseguibile del componente (per esempio Dll o Exe) In Windows i CLSID delle CoClass dei componenti disponibili sono registrate nel Registry di sistema

Creazione di un server COM locale (server in un file.exe) Passi necessari 1.Definire le interfacce specifiche del componente 2.Definire i parametri delle CoClass del componente 3.Fornire limplementazione delle interfacce esportate dal componente 4.Fornire una class factory per creare le istanze del componente quando richieste dai client 5.Implementare lentry point (main) del server 6.Impostare il registry per lattivazione del componente

Passo 1 Interfaccia del componente IDL è un linguaggio che permette di definire interfacce e librerie di tipi (contenenti CoClass) Attributi IDL –Identificano le caratteristiche delle interfacce/CoClass –Attributo [uuid]: definisce gli IID o CLSID –Attributo [oleautomation]: definisce che linterfaccia sarà usata per comunicazione inter-processi –Attributo [version]: definisce il numero di versione –Attributo [helpstring]: descrizione testuale –(per altri attributi vedere US/library/8tesw2eh(VS.80).aspx) US/library/8tesw2eh(VS.80).aspx MIDL (Microsoft IDL compiler) permette di compilare linterfaccia. Genera 3 file – _h.h: Contiene le definizioni delle interfacce (da usare come header file) – _i.c: Contiene gli IID e CLSID (usare in tutti I server e client) – _p.c: Contiene il codice di proxy/stub per client-server distribuiti

Interfaccia IDL (esempio) [uuid(5C6CD72C-8FDE BE-B2BB2D4110CB), version(1.0), oleautomation, helpstring("Interfaccia IMyCounter")] interface IMyCounter : IUnknown { HRESULT Reset( [in] int val); HRESULT Inc( ); HRESULT GetVal( [out,retval] int* val); }; Le specifiche sui parametri di input/output sono necessarie per la corretta implementazione della comunicazione fra i processi (eventualmente in rete)

Passo 2. Type Library Una TypeLibrary contiene informazioni sulle CoClass incluse nel componente e le interfacce da esse implementate [uuid(2EBFC E-41f5-B80B-98BDCDD8AD96), version(1.0), helpstring("TypeLib contenente il server locale (coclass) dei componenti MyCounter")] library CounterLocalServerLib { importlib("stdole32.tlb"); [uuid(34898D9A-B306-42ee C2B151)] coclass MyCounter { [default]interface IMyCounter; };

Passo 3 (i/iii) Implementazione del componente Implementazione di tutte le funzionalità esportate dalle interfacce del componente Può essere realizzata in un qualsiasi linguaggio facendo riferimento agli IID e CLSID definiti in IDL Limplementazione può consistere di uno o più moduli indipendentemente dal numero delle interfacce implementate Va sempre implementata anche linterfaccia IUnknown

Passo 3 (ii/iii): Esempio in C++ class MyCounter : public IMyCounter { public: MyCounter(); virtual ~MyCounter(); // Metodi per implementare IUnknown STDMETHODIMP QueryInterface(REFIID riid, void** pIFace); STDMETHODIMP_(DWORD)AddRef(); STDMETHODIMP_(DWORD)Release(); // Metodi per implmentare IMyCounter STDMETHODIMP Reset(int val); STDMETHODIMP Inc(); STDMETHODIMP GetVal(int* val); private: DWORD m_refCount; int val; };

Passo 3 (iii/iii) Implementazione di QueryInterface STDMETHODIMP MyCounter::QueryInterface(REFIID riid, void** pIFace){ if (riid == IID_IUnknown) *pIFace = this ; else if (riid == IID_IMyCounter) *pIFace = this ; else { *pIFace = NULL; return E_NOINTERFACE ; } ( (IUnknown*) (*pIFace) )->AddRef(); return S_OK ; }

Passo 4. Class Factory La class factory è necessarie per poter creare più istanze dello stesso componente per richieste provenienti da client diversi Le class factory implementano linterfaccia standard IClassFactory class MyCounterClassFactory : public IClassFactory { public: MyCounterClassFactory(); virtual ~MyCounterClassFactory(); // IUnknown …… // IClassFactory STDMETHODIMP LockServer(BOOL fLock); STDMETHODIMP CreateInstance(LPUNKNOWN pUnkOuter,REFIID riid,void** ppv); private: ULONG m_refCount; };

Passo 5. Server Entry Point Main che viene eseguito quando viene lanciato leseguibile del server –Registra tutti i tipi del componente (CLSID e IID) nel registry di sistema (LoadTypeLibEx) –Crea gli oggetti ClassFactory per ogni componente gestito dal server e li registra nel sistema (CoRegisterClassObject) in modo che possano essere trovato attraverso CoGetClassObject –Rimane in attesa che il client smetta di usarlo client

Server object counting Il server viene attivato da COM quando un client fa richiesta Il server deve rimanere attivo fino a quando almeno un client sta usando almeno un oggetto residente sul server, poi terminare Per questo motivo, il server conta gli oggetti attivi (usati dai client), e quando il contatore va a 0 termina –La terminazione può per esempio avvenire attraverso un messaggio che interrompe il ciclo di attesa (o attraverso altre primitive di sincronizzazione)

Object counting e reference counting Lobject counting è di solito associato alla costruzione/distruzione degli oggetti –Per ogni nuovo oggetto creato, si incrementa il contatore di 1 –Per ogni oggetto distrutto lo si decrementa di 1 A sua volta, la distruzione degli oggetti è regolata dal meccanismo di reference counting (AddRef-Release) –Quando viene rilasciato lultimo reference, loggetto viene distrutto

Class Factory e Reference Counting Per le class factory lincremento del contatote di reference (AddRef) effettuato in fase di registrazione (CoRegisterClassObject) non sarebbe mai controbilanciato, rendendo così impossibile terminare il server quando non è più usato da nessun client Soluzione –Non uso reference counting per le class factory (annullando così leffetto problematico di CoRegisterClassObject) –Quando una class factory viene richiesta per la prima volta con CoGetClassObject, COM invoca IClassFactory::LockServer(TRUE) –Com gestisce il reference counting relativo al client, attraverso un oggetto proxy, e quando viene rilasciato lultimo riferimento invoca ICLassFactory::LockServer(FALSE) Quindi –Non cè bisogno di usare reference counting, perché viene gestito automaticamente da COM –Il contatore degli oggetti sul server può essere gestito opportunamente attraverso IClassFactory::LockServer

Passo 6. Impostazioni per lattivazione del componente Nel Registry di sistema va registrata lassociazione fra CLSID principale del server e file eseguibile che va lanciato per attivare il server Bisogna creare opportune chiavi sotto HKEY_CLASSES_ROOT per registrare –Lassociazione fra CLSID del server, e il per percorso del file eseguibile –Lassociazione fra LIBID della TypeLib e il percorso del file contenente la typeLib –Lassociazione fra gli IID delle interfacce e le proprietà delle stesse

Meccanismi di riuso in COM In COM esistono due principali forme di riuso di componenti (e delle loro interfacce) per implementare nuovi componenti –Delega (delegation) –Aggregazione (aggregation)

Riuso attraverso delega Si riusano i servizi di un componente esistente per implementare alcune funzionalità di un nuovo componente

Delega: cenni allimplementazione e alluso Il componente esterno (outer object) è client del componente interno (inner object) Generalmente, il componente interno non è visibile allesterno Limplementazione del componente esterno controlla il ciclo di vita del componente interno –definisce un puntatore al componente interno –crea il componente interno quando opportuno (per esempio in fase di creazione del componente esterno) –usa il componente interno attraverso le opportune interfacce –Rilascia il componente interno quando opportuno (per esempio quando viene rilasciato il componente esterno) In questo modo è inoltre possibile –usare le interfacce del componente esistente come base per implementare le medesime interfacce nel nuovo componente –aggiungere (se necessario) codice prima e/o dopo linvocazione dei metodi del componente esistente

Riuso attraverso aggregazione Si espongono le interfacce di un componente esistente come parte di un nuovo componente senza modificarne il comportamento

Aggregazione: cenni allimplementazione e alluso Il componente interno viene creato in modo da delegare le chiamate a IUnknown allinterfaccia IUnknown del componente esterno Il metodo QueryInterface del componente esterno restituisce (per le opportune interfacce) un puntatore al componente interno In questo modo è possibile –usare lo stesso esatto comportamento di un componente esistente senza conoscerne i dettagli comportamentali –evitare il codice di delega dei servizi –aumentare le prestazioni evitando troppe chiamate di procedura annidate

Aggregazione: creazione del componente interno (cenni) Attraverso i metodi di creazione della COM library (CoCreateInstance, CoGetClassObject, IClassFactory::CreateInstance) –Tali metodi ricevono un puntatore (pUnkOuter) allinterfaccia IUnknown cui delegare le chiamate –Lidea è di usare tale parametro in modo che, se il puntatore pUnkOuter è diverso da NULL, le chiamate vengano delegate alloggetto da esso puntato Limplementazione dei componenti deve tenere opportunamente conto del puntatore pUnkOuter affinché il componente sia aggregabile Tenere conto dellaggregabilità costa poche linee di codice (circa 10) quindi è generalmente consigliato nellimplementazione del componente

Alcuni riferimenti utili Principali Interfacce COM – url=/library/en-us/com/html/aa9b11ae ff-afe7-00c34bd235e3.asphttp://msdn.microsoft.com/library/default.asp? url=/library/en-us/com/html/aa9b11ae ff-afe7-00c34bd235e3.asp