I sistemi operativi si susseguirono, fino alla comparsa di Windows NT, il primo s.o. in cui ci son già implementati dei concetti significativi.

Transcript

1 DCOM, COM,.NET 2 Quando si parla di architetture proprietarie, si intendono tutta una serie di cose, in particolare si pensa alla storia dei sistemi operativi, in questo caso del S.O. di Microsoft. Mentre con gli altri s.o. si lavorava con le linee di comando, dietro al s.o. di Microsoft c'era l'idea di lavorare con le finestre, modo che ovviamente ha ampliato la fascia di utenza. Si ricordi che tale idea nasce quando ancora l'architettura dei calcolatori era molto limitata, in sostanza tale idea nasce indipendentemente dai supporti di gestione a cui noi siamo abituati. I sistemi operativi si susseguirono, fino alla comparsa di Windows NT, il primo s.o. in cui ci son già implementati dei concetti significativi. Si susseguirono altre architetture, fino all'architettura.net che non rappresenta un s.o. ma un modo di poter supportare di sotto anche s.o. diversi: rappresenta un momento di forte soluzione di continuità a livello architetturale, ed è propria questa continuità all'indietro uno dei principi fondamentali e di maggiore impatto da mantenere sempre quando si lavora. 3 i sistemi operativi ci interessano abbastanza poco, difatti quello di cui vogliamo, in questo capitolo, discutere è che il tutto deve funzionare qualunque sia il s.o. sottostante: non vogliamo avere una visione di sistema. 4 Le DLL, l'acronimo per Dynamic Linked Libraries, creazione di Microsoft, sono delle librerie ad aggancio dinamico. Avere un sistema che deve caricare tutto il programma all'inizio vuol dire avere un sistema che sta usando molto male le risorse; Pertanto Microsoft procede con un idea (non sua di proprietà) che il programma sia costituito da componenti che possono essere caricati dinamicamente: le DLL. Quindi il programma nella fase iniziale carica solo una parte, poi, solo su bisogno, durante l'esecuzione, con conseguenti tempi allungati di ritardo, carica le parti che gli servono. Allo stesso livello di importanza vi è l'idea delle finestre di s.o. per l'interazione grafica vicina all'utente. Tale idea non nasce in casa Microsoft. Resta comunque un idea pervasiva nelle architetture. 5 Quando si parla di DLL, si dice quindi che il programma può essere spezzato in parti, le quali possono essere caricate dinamicamente. Si noti che parlando di DLL, si parla sì di componenti che vengono caricati dinamicamente, ma ci si può chiedere se tale caricamento dinamico sia un caricamento per sempre o no. Evidentemente, quello che succede è che se un programma non ha più bisogno della DLL appena caricata, tale DLL verrà quindi scaricata. Un architettura fatta in questo modo è molto efficiente perché consente di risparmiare risorse. 200 Stefano Di Monte

2 Caso di studio: Si pensi alla presenza di due programmi che hanno bisogno della stesa DLL, questi due programmi <<useranno la stessa DLL?>>, se è già stata caricata da uno dei due, <<l'altro dovrà ricaricarla?>> Per applicare il principio di riuso, le DLL possono essere condivise. Tutto ciò si scontra, ovviamente, con l'esecuzione contemporanea da parte di più programmi che potrebbe dare dei problemi se fosse presente uno stato...quindi o si lavora senza stato o si effettuano delle operazioni potenzialmente pericolose in mutua esclusione: tipicamente le DLL non hanno stato, il che non vuol dire che lo stato è completamente assente, bensì che c'è ma che non si può cambiare! (lo stato è nel cliente!). Il non avere stato consente un caricamento delle stesse dll facile ed inoltre il fatto che quest' ultime eseguono nello spazio del programma che le invoca. <<Come si fa a capire se un modulo deve rimanere in memoria? E se fosse così, fino a quando ci deve rimanere?>> La soluzione Java prevede un Garbage Collector...qui invece non si lavora con questo strumento, ma si lavora con i componenti, quindi in modo esplicito: chi ha bisogno di una cosa lo deve dire magari implementando un contatore che verrà incrementato ogni qual volta quel determinato componente carica quella dll e verrà decrementato ogni qual volta quella stessa dll viene scaricata ; quando il contatore ha valore 0 la dll viene riportata in memoria. Questo modo di lavorare si chiama Reference Counting. 6 In realtà, gli stessi s.o. sono delle dll: sono composti da componenti che sono caricati dinamicamente, ed è evidente comunque però, che in un sistema operativo le cose che sono caricate rimangono caricate perché ovviamente una macchina lavora affinché il s.o. sia tutto presente... Questo modo di lavorare risale fino alle prime versioni di Windows. 7 I s.o. di Microsoft hanno adottato gli stessi principi quando ancora non c'era un architettura a 32 bit in cui si riuscisse ad implementare in modo ben fatto il multi-tasking. In sostanza questo modo di lavorare, caricando dinamicamente librerie, riusciva a produrre un buon sistema di interfaccia finestre-utente anche senza alcun supporto per i thread, in particolare anche se dal punto di vista di principio, il s.o. consentiva di avere un unico processo, si riusciva a lavorare bene con una specie di multi-thread finto, dando l'illusione di avere a che fare con un sistema multithread (dato che non c'era un kernel ben fatto...). Ovviamente, queste cose funzionano bene quando di sotto c'è un kernel ben fatto (Win32). Reti di Calcolatori LM 201

3 8 Windows NT viene considerato un evento significativo in termini di s.o. non tanto in termini di supporto, di middleware o di entità supportate perché, in questo s.o. cominciano a comparire dei processi leggeri ben fatti e si implementa abbastanza facilmente l'idea di un processo pesante che racchiuda altri processi più leggeri. In generale, Microsoft quando può, cerca di unificare una serie di meccanismi in modo che siano standard per le sue architetture: in particolare si comincia ad avere un idea molto precisa del fatto che tutte le entità che sono disponibili, siano oggetti. Tipicamente sono oggetti sia le entità applicative (ad esempio i thread comandati da un utente finale) e sia le entità a livello di kernel. In sostanza l'idea è quella di avere una molteplicità di componenti e di avere dei punti di vista comuni. Le architetture di Microsoft arrivano a determinare uno scenario di interazione sicuramente molto flessibile e molto vario; questo perché man mano i s.o. cambiano, aggiungono componenti e modalità, cercando di avere un unico modello di interazione. Altra cosa che è tipica delle architetture Microsoft è l'idea degli eventi: in particolare, a basso livello, gli eventi sono un concetto assolutamente pervasivo nell'architettura. Per Microsoft gli eventi hanno una implementazione locale (modello ad eventi locale) e non c/s! 9 Quando si parla di modello ad eventi, in Microsoft si tende a ricordare lo slogan: Don't call me I call you ossia il modello Hollywood. In sostanza non si lavora c/s, in cui vi è un qualcosa (ad esempio un cliente) che si mette in attesa di qualcos'altro, bensì si ha un modello in cui qualcuno si registra su qualcun' altro e quest'ultimo gli dirà di lui, in particolare quando si avrà una risposta. Il sistema ad eventi è molto importante perché in Microsoft le finestre sono basate per l'appunto su questo modello: io ho una finestra nel sistema, e questa finestra tipicamente rappresenta un area associata ad un processo di gestione; quando il mouse va su questa finestra, solo in questo momento, in generale si vuole attivare e mandare una informazione al processo di gestione che c'è dietro. Quindi tipicamente, in architetture tipo windows NT, i processi sono fortemente dipendenti dagli eventi che arrivano dalla tastiera. Si usa un modello ad eventi, perché se ad esempio ci troviamo in una situazione di schermo, in tale situazione, sullo schermo potrebbero esserci più finestre: quindi quando in realtà tocchiamo il mouse in una posizione si manda un evento a tutti i gestori delle finestre che si trovano in quella posizione: è un modello uno-a-molti, pertanto si mandano gli eventi in modo pervasivo! In generale una delle cose sempre presenti nelle architetture Microsoft: se una entità è in grado di eseguire, ha tipicamente una coda di eventi, ossia una coda di messaggi che deve processare (se attivato) diretti verso di lui e che vengono generati per varie ragioni (per IN/OUT, dall'utente, ecc), coda che deve gestire bene. NOTA: nelle prime architetture le cose erano un po' più complicate perché c'era un unica coda per tutti i processi Stefano Di Monte

4 10 In realtà Microsoft non ha inventato gli eventi, ma gli ha usati in modo originale, ossia in maniera molto pervasiva SOLO a livello locale (si ricordi che il modello ad eventi è in generale un modello che può essere implementato su molti nodi). In particolare le prime architetture implementavano gli eventi con i DDE, ossia le code degli eventi per le varie attività, e funzionavano malissimo: il comportamento, ad esempio, non era fail-safe. 11 Per quanto riguarda i messaggi ne abbiam già parlato... <<Cosa sono le Windows procedure?>> Poniamoci a livello applicativo... A questo punto supponiamo di essere un processo che deve gestire una finestra: l'utente ha scritto dei dati su questa finestra ed io devo andarli a leggere. A basso livello, quando qualcuno focalizza tale finestra io vengo attivato, ovvero un messaggio arriva sulla mia coda. C'è però anche un problema di gestione di più alto livello: cioè quando vengo attivato devo aver prima specificato a qualcuno cosa fare quando qualcuno ha scritto certi dati che io devo trattare. Chiaramente il trattamento di questi dati è a vari livelli, ad esempio, il ridimensionamento delle finestre vien fatto dal s.o. non dall'utente (ed è bene che tutte le finestre ereditano questa funzione), mentre alcune situazioni devono essere gestite esplicitamente dall'applicazione. <<Come fa a dividere la parte di s.o. da quella gestita dall'applicazione?>> Tipicamente, Microsoft suggeriva all'utente di scrivere dei componenti, ossia delle funzioncine, che chiamava callback, che rappresentavano il codice da eseguire quando la finestra era stimolata da un qualche comportamento applicativo. A questo punto, quindi, la funzione di callback veniva automaticamente messa in esecuzione dal s.o. così come fosse una funzione di sistema (ad esempio, una funzione di ridimensionamento di una finestra, ecc). L'utente quindi inseriva, con l'aiuto di qualche wizard, delle sue parti di logica per gestire certe situazioni specifiche. Pertanto, la Windows Procedure, era in realtà un insieme di funzioni di gestione, specificate una volta per tutte dall'utente che poi in seguito avrebbe potuto disinteressarsi del tutto, e che il sistema operativo poteva chiamare, dal basso, su bisogno! NOTA: una windows procedure eventualmente, per ogni programma corrispondente. Pertanto, qui la cosa è molto più flessibile di un c/s ma più complessa. 12 La figura qui presente, dice semplicemente, che io mi mettevo in attesa di un evento, e quando questo arrivava, venivo così segnalato da qualcuno che stava di sotto, per tale motivo upcall (push del framework), che si era verificato l'evento corrispondente tramite messaggio. Reti di Calcolatori LM 203

5 13 Microsoft è, non solo sul mercato dei s.o. per piccoli sistemi con un modello architetturale, ma anche sul mercato applicativo, quindi tende a fornire una serie di applicazioni (come office, ) integrati più o meno tra di loro. Sicuramente, Microsoft tende a fornire un modello molto preciso per componenti, e con questi si intende degli aggregati capaci di eseguire cose che tipicamente tendono a dipendere in maniera molto forte da un container, quindi un gestore che gli contiene e che li descrive OLE Questa definizione, è volutamente fumosa, perché quando si parla di Microsoft si parla di un modello di interazione (spesso invisibile all'occhio dell'utente finale) che è sicuramente originale. Stiamo parlando di Object Linking Embedding (OLE)! IMPORTANTE: in Microsoft si parla spesso di Object, in realtà l'architettura Microsoft non è un architettura ad oggetti perché non c'è un idea di oggetti e classi! Sicuramente però c'è l'idea di dire che si è ad oggetti... Le OLE sono un idea molto precisa di avere (almeno inizialmente) dei documenti che possono essere letti e capiti da contenitori diversi; per contenitori diversi si intende, ad esempio un documento potrebbe essere il contenuto di un word processor che ne fa quindi da contenitore; a sua volta però, nel documento in questione ci potrebbe essere del contenuto che invece serve per fare delle presentazioni, quindi che in parte è powerpoint, e tale parte deve afferire ad un contenitore powerpoint (esempio nella figura seguente) (e si può continuare dicendo che all'interno di questa ci potrebbe essere un altra sotto-parte che deve afferire ad un contenitore diverso ecc ecc): c'è un idea molto forte di interoperabilità! 204 Stefano Di Monte

6 Ognuna delle parti di un documento, se diverse in termini di contenitore al quale ascrivono, deve pertanto essere gestita dal rispettivo contenitore di afferenza: integrazione dinamica di una serie di contenitori! In particolare, però, e lo si capisce dal nome stesso delle Object Linking Embedding, ciò che è all'interno del documento e che ascrive ad un contenitore esterno: può puntare a questo contenitore esterno (linking) oppure è contenuto (embedded) all'interno del contenitore di appartenenza (ad esempio un documento powerpoint che ha al suo interno, quindi privato e non visibile all'esterno, la parte di word). 16 Le OLE sono un ottima soluzione, ma sicuramente ce ne sono state altre di implementazioni... Assomiglia un po' ad una specie di dll, perché vista da più programmi GUID Quando lavoriamo con un architettura Microsoft lavoriamo con una serie di entità, in particolare: -) entità di kernel -) processi -) spazi condivisi -) code -) entità applicative L'idea è molto adatta per fare della distribuzione; tipicamente, tutti gli oggetti interessati hanno un nome unico, e la scelta va verso quello che viene chiamata Globally Unique IDentifier (GUID), che è un nome da 16 byte (128 bit) in cui mettiamo una serie di configurazioni assolutamente uniche per identificare quel componente. La scelta dei GUID è una scelta dei primi anni '80, e tipicamente l'unicità viene ottenuta con il nome di una certa macchina e poi un timestamp relativo a quella macchina (per macchina si intende la macchina di creazione di quell'oggetto), e lavorare con questi GUID garantisce che si è in grado di dare dei nomi unici a tutte le entità di cui si ha bisogno, ad esempio classi ed interfacce. La scelta dei nomi unici non è interna a Microsoft, ma usa uno standard della OSF (Open Software Foundation), ossia usa lo stesso standard pensato da quest'ultimo per RPC di DCE (le UUID -Universally Unique ID-). 18 Su ciò, comincia quindi a farsi strada un esigenza molto forte di standardizzazione, in particolare quando i processi cominciano ad essere presenti e facili da manovrare all'interno di un sistema operativo, nasce un problema molto forte di interazione e ovviamente, di integrazione tra i processi stessi. Reti di Calcolatori LM 205

7 In casa Microsoft, tutto ciò prende il nome di Component Object Model (COM) (che poi diventerà abbastanza aperta come standard e non come implementazione). L'idea di COM è di avere dei componenti diversi, che si possono offrirsi reciprocamente dei servizi; lo standard COM definisce quindi, come questi servizi possono essere offerti tra i componenti, e lo fa organizzando una relazione cliente/servitore. Quindi di sotto ci sono gli eventi e ci sono le dll, ma di sopra si mostra un meccanismo di comunicazione c/s sincrono bloccante indipendentemente dal linguaggio in cui è scritto il cliente e dal linguaggio con cui è scritto il servitore. COM è un architettura proprietaria ma non legata ad un linguaggio, pertanto è multi-linguaggio! NOTA: così facendo siamo molto più vicini ai middleware. 19 Di base, COM utilizza nel distribuito le RPC standard (molto simili a quelle di SUN): meccanismo c/s standard. Tale affermazione potrebbe assomigliare all'idea di CORBA che dice che in qualunque istante ed in qualunque linguaggio, un cliente può invocare qualsiasi servitore, usando stub e skeleton, indipendentemente dal nodo sul quale essi si trovino; in realtà CORBA finisce qua...in Microsoft invece si dice che le cose vengono, se possibile, ottimizzate per dove sono al momento residenti, ossia, se la comunicazione è: realmente distribuita allora si useranno delle RPC vere sullo stesso nodo, quindi tra processi che sono sullo stesso nodo, allora la performance della comunicazione viene ottimizzata (modello ad eventi). Punto di vista più ottimizzato ma sicuramente più complesso! 20 In realtà dietro a COM, c'è, come si suol dire, il modello di COM. Quest'ultimo è un modello che è, in sostanza il modello di Microsoft per come sono fatte le applicazioni. Il modello di COM viene usato da tutte le cose che mettiamo in gioco, in modo molto pervasivo, ed è anche assolutamente compatibile con il meccanismo delle dll: Microsoft cerca di integrare in COM tutta la sua filosofia e tutti i suoi modi di lavoro. 21 In generale in Microsoft ci sono sicuramente delle interfacce: e qualunque servizio che può essere richiesto da qualcuno deve avere un interfaccia, che avrà un suo nome UNICO, e che per poter essere richiesta deve essere disponibile, e per far ciò deve essere presente un qualche server che la metta a disposizione. L'interfaccia più famosa è l'interfaccia che si chiama IUnknow: è l'interfaccia delle interfacce! Quest'ultima è fondamentale perché tutte le interfacce derivano da questa. In generale un oggetto di Microsoft non è un oggetto ma è un componente, nel senso che non ha una classe ma è inteso come un prototipo, è inteso nel senso che ha delle possibilità da offrire ad altri, e 206 Stefano Di Monte

8 tipicamente le sue offerte sono realizzate tramite interfacce. Le sue interfacce normalmente sono organizzate in una serie di interfacce diverse associate al componente tramite una tabella che le mette insieme. In sostanza quando si fa un componente di Microsoft, vuol dire che posso produrre un qualche cosa da mettere in esecuzione, e quando metto in esecuzione, le interfacce di tale componente sono tutte messe insieme in una Virtual Method Table (VMT). La VMT rappresenta quindi l'insieme delle interfacce di servizio di un certo oggetto che è quindi qualificato in termini delle cose che può offrire attraverso le sue interfacce. Un interfaccia per Microsoft, è una sequenza di slot, è standardizzata e capita da tutti, con il suo ID a 128 bit, con dei metodi che hanno un certo nome, e che in realtà sono dei puntatori al codice dei metodi stessi. Pertanto, se quest'interfaccia è IUnknow, questa sarà fatta di tre slot: il primo slot è il puntatore che dice dove sta il codice della QueryInterface il secondo slot è un puntatore che dice dove sta il codice della AddRef il terzo slot dice dove sta il codice della Release. Se avessi un interfaccia con 10 metodi fatta da noi, avrei da qualche parte nella VMT del mio componente, un interfaccia che ha 10 slot, numerati da 0 a 9 e con il primo slot come puntatore al primo metodo, il secondo slot come puntatore al secondo metodo e così via... In realtà il componente ha un suo front-end che è la VMT, che è un insieme di interfacce, tutte identificate da degli ID assolutamente unici; conoscendo le interfacce è possibile conoscere come sono fatti i metodi e sappiamo che se volessi, per esempio nel caso di IUnknow, chiedere AddRef dovrei fare un +1 rispetto all'indirizzo iniziale (+2 per la Release). Si raccontano tutti questi dettagli implementativi perché l'utente è fortemente coinvolto in quest'ultimi: spesso sono visibili e quindi bisogna conoscerli! Difatti quando otteniamo un riferimento all'oggetto, il riferimento all'oggetto non è un entità opaca ma in realtà è un entità visibile, che va a finire sulla VMT: l'equivalente dell' Obj Ref di CORBA, qui in Microsoft è un puntatore alla VMT, e se io volessi riferire uno specifico metodo bisogna che io vada a riferirlo nella sua specifica posizione. La causa di tutto questo eccesso è data dal fatto che questa è una struttura astratta modellata sulle tabelle dinamiche di C++: deriva conseguentemente dal supporto di questa architettura. Il vantaggio di questa indirettezza è che è possibile cambiare il codice dei metodi semplicemente cambiando i puntatori, e quindi non c'è un legame statico con il codice. 22 Reti di Calcolatori LM 207

9 In generale i componenti COM implementano molte interfacce e non una sola come in CORBA! Piccola considerazione di dettaglio: Supponiamo due componenti diversi con eventualmente due VMT differenti, e supponiamo che entrambi abbiano l'interfaccia I4, però è evidente che, dato che i componenti sono diversi e che ogni componente decide le sue interfacce, quello che succede in questo caso è che la posizione nelle VMT dell'oggetto A dell'interfaccia I4 potrebbe essere diversa dell'interfaccia I4 di un altro componente (vedi figura seguente). Non possiamo quindi pensare di derivare staticamente una conoscenza della posizione dell'interfaccia perché ogni singolo componente ha il suo modo di dichiarare le interfacce, in un ordine diverso, e quindi a questo punto ogni VMT ha una storia a sé, e l'ordine, quindi, con cui le interfacce si susseguono in queste è assolutamente dipendente dal componente. Devo cercare di preparare un qualche cosa che mi consenta di recuperare, indipendentemente dalla posizione, ad esempio, il secondo metodo dell' interfaccia I4... RICORDA: c'è ereditarietà tra le interfacce! 23 Registry E' un piccolo database di configurazione presente su tutte le macchine Microsoft; è quell'entità locale in cui vengono spalmate una serie di informazioni sulla configurazione delle installazioni correnti. Tipicamente il registry, un main system locale molto primitivo (definito primi anni '80), contiene tutte le UUID dei componenti windows attraverso le quali è possibile sapere la posizione corrente di questi all'interno del file system corrente. Le architetture COM hanno bisogno di un registry, perché tutte le volte che un server o un componente dev'essere attivato, tipicamente si va sul registry tramite l' UUID, quel numerino unico, per trovare la posizione nel file system del componente corrispondente. Ovviamente, quando si cerca un qualunque componente, ci si aspetta di trovarlo sempre nel registry che normalmente è solo un repository assolutamente locale, non ha quindi nessuna capacità, a livello di principio, di trovare le cose in altre macchine. Tornando al discorso delle interfacce: L'interfaccia fondamentale è l'interfaccia IUnknow, che è fatta di tre metodi: QueryInterafce, AddRef, Release. In generale ogni singolo componente ha la IUnknow come prima interfaccia: i componenti COM sono assolutamente forzati nella prima interfaccia disponibile che deve essere quella fondamentale, ossia la IUnknow. 208 Stefano Di Monte

10 24 Il primo metodo dell'interfaccia IUnknow si chiama QueryInterface, il quale è espresso in un linguaggio che è l' IDL di Microsoft, ed il funzionamento è il seguente: io entro con un UUID che rappresenta l'interfaccia che mi interessa (il mio input); dopodiché attraverso la QueryInterface si chiede per l'appunto se un componente implementa un interfaccia o meno (utilizzando l' UUID prima citato): se l'implementa il risultato sarà un successo, ed in particolare mi viene dato come parametro d'uscita un puntatore al codice che mi interessa, ossia l'indirizzo di inizio dell'interfaccia di interesse, attraverso il quale posso finalmente richiederne il metodo avendo la posizione di base (quindi se mi dovesse interessare il metodo 2 spiazzerò di due rispetto all'indirizzo di base). NOTA: non solo in questo ambiente si lavora in questo modo, l'unica differenza è che qui l'utente è al corrente di come funziona il tutto: l'utente vede questi riferimenti, vede l'invocazione della QueryInterface. Gli altri due metodi (AddRef e Release) sono metodi relativi al reference counting, in particolar modo: -) AddRef consente di aggiungere un riferimento ad un oggetto: viene incrementato il contatore di reference counting -) Release consente di togliere un riferimento ad un oggetto: decrementa il contatore di reference counting. Queste tre sono viste come funzioni fondamentali! 25 Tutti gli oggetti COM devono, ad alto livello, avere questo tipo di cosa! La scelta di Microsoft è una scelta molto esplicita, in quanto lascia tutta la gestione dinamica sotto la responsabilità dell'applicazione: in sostanza, quando l'utente ha bisogno di un componente, deve, come prima cosa, andare ad incrementare il suo reference count, in modo tale che quel componente sia segnalato in memoria come acceduto, e naturalmente, è compito dell'utente stesso, successivamente, nel momento in cui non ne abbia più bisogno, fare una Release (decrementando il contatore prima citato). Si noti che questo modo di lavorare non è semplicissimo: se io passo un riferimento ad un altro oggetto, io prima di passarlo, o quando lui lo riceve, devo incrementare il reference count! Tutto è lasciato al piano di sopra, quindi all'utenza, non in modo automatico come succede con un garbage collector (il quale automaticamente butta via gli oggetti non più riferiti). Lo svantaggio di un garbage collector è che quando esegue in contemporanea con l'esecuzione normale, appesantisce di molto il tutto con probabile conseguente blocco di quest'ultima e presenza di tempi di risposta elevati, aumento della latenza ecc ecc. Col reference counting tutto questo non esiste, perché è l'utente stesso che dice in ogni momento se un componente gli serve o meno, e la liberazione della memoria avviene solamente quando egli fa un'azione (Release): se Release e poi count=0 allora l'oggetto viene eliminato. Reti di Calcolatori LM 209

11 Naturalmente se l'utente non fa le release gli oggetti rimangono lì inutilizzati impegnando risorse inutilmente. 26 C'è ereditarietà tra le interfacce di Microsoft (e non delle implementazioni), e queste sono tutte interfacce che, in termini di terminologia, hanno tutte come lettera iniziale una I e poi il nome dell'interfaccia. Come già detto, l'interfaccia di base è l'interfaccia IUnknow e da questa derivano tutte le interfacce successive dei componenti. 27 Il punto di vista di Microsoft va nel senso opposto delle classi: per l'appunto non classi, ma oggetti che sono prototipi a sé stanti; quindi, in COM non si hanno le descrizioni uniche di ogni componente perché ogni singolo componente ha un suo comportamento diverso: non c'è l'idea di una classe a cui spediamo tutta una serie di componenti ma c'è maggior libertà. Gli ambienti che adottavano questo stesso punto di vista, non vedevano di buon occhio l'ereditarietà delle classi perché sostenevano che quest'ultima, è una sorta di deroga al principio di astrazione: quando creo una classe e da questa creo degli oggetti, se poi in seguito faccio ereditare da questa classe un'altra classe, è come se mostrassi il comportamento della classe precedente alla classe successiva perché effettivamente incorpora tutta la struttura delle precedenti. Questo modo di lavorare era visto un grosso problema in termini di rompere il principio di astrazione: in sostanza una classe derivata incorporava il comportamento della classe per così dire madre; c'era quindi tutto un filone di proposte che andava nel senso di non avere ereditarietà fra classi. Sicuramente però COM è un ottimo esempio di una strutturazione di ambiente a componenti (quindi più su di un linguaggio) che si basa su questo: ci sono delle interfacce, le quali sono in ereditarietà, ma non si parla di ereditarietà di codice! Si parla di ereditarietà di interfaccia! Ogni singolo componente poi dovrà dire quali sono i pezzi di codice per i suoi metodi: riempire la VMT mettendo per ogni entry il puntatore al codice corrispondente è un compito tipico del singolo componente, non c'è quindi una classe che guida questo mappaggio! Pertanto se avessimo due componenti con la stessa struttura di VMT, uno dei due potrebbe puntatore al codice Pippo, per l'interfaccia I4, e l'altro potrebbe puntare al codice Pluto, proprio perché ogni componente ha la responsabilità di scegliere il codice di gestione dei propri metodi: ogni componente è un prototipo a sé stante. Tutto ciò lascia molta libertà, ma ovviamente rende difficile questo settaggio e soprattutto ha un ventaglio di decisioni... In contemporanea, accanto all'idea di ereditarietà, nei sistemi che venivano chiamati delegati, in cui cioè si lavorava a prototipi c'erano due forme di supporto per il riuso, assolutamente non pensate per l'ereditarietà Pertanto, COM è basato su due modelli: Contenimento/Delegazione prescrive e rende possibile che, un componente COM possa avere al suo interno altri componenti, i quali sono suoi privati. Tali componenti sono al suo interno perché l'oggetto che fa da front-end ha una certa tabella VMT, e siccome non vuole implementare alcune interfacce ma le vuole delegare, 210 Stefano Di Monte

12 queste interfacce (che potrebbero essere due come raffigurato nella figura seguente) sono pertanto delegate a due oggetti interni, i quali quindi, sono contenuti nell'oggetto esterno e a questo punto sono un insieme unico che costituisce l'oggetto e fornisce i metodi di quell'oggetto. NOTA: nei sistemi ad oggetti (ad esempio Java) non c'è mai quest'idea di contenimento di oggetti: avere un modello del genere renderebbe complessa la struttura. Aggregazione un oggetto implementa al proprio interno non tutti i metodi di cui ha bisogno, e lascia alcune interfacce, quindi alcuni metodi, che saranno implementati da altri componenti esterni che sono considerati aggregati con lui. In questo caso, l'oggetto esterno non fa neanche da passacarte, ma delega in modo forte una parte della sua interfaccia a più oggetti; quindi potrebbe succedere che quando si crea un oggetto esterno, non creo anche gli altri oggetti che potrei invece creare su bisogno o addirittura potrebbe essere che una parte dell'interfaccia dell'oggetto esterno venga gestita dagli oggetti I1 e I2 (vedi figura seguente) senza attivare tutto il resto. Quindi l'aggregazione è una strutturazione un po' più dinamica (sottolineata maggiormente nelle architettura di seconda generazione). Riassumendo, stiamo trattando modelli in cui non vi è ereditarietà ma in cui vi sono tutta una serie di meccanismi che sono visibili direttamente dall'utente. NOTA: COM è un modello senza classi! 31 COM comincia a far vedere una serie di altre entità in gioco: non abbiamo classi ma abbiamo qualcuno che deve occuparsi di gestire gli oggetti, di attivarli, di garantire che siano visibili ecc ecc. In sostanza si devono avere delle factory! In generale, quello che succede è che se c'è un esigenza di creazione, c'è un interfaccia che si chiama FACTORY che consente di avere e determinare in modo standard una serie di funzionalità che sono necessarie per lavorare in modo corretto ed avere qualcuno che sia in grado di creare, ma soprattutto gestire, tutti gli oggetti di cui ce n'è bisogno e i cui servizi possono essere richiesti. Pertanto esiste un interfaccia che si chiama IclassFactory che stabilisce per l'appunto come si devono comportare le factory. NOTA: Le factory non sono oggetti che consentono di generare solo oggetti di un certo tipo, ma consentono di gestire una molteplicità di oggetti (il concetto di classe qui non è proposto per niente). Quindi ci potrebbero essere un po' di factory (ma anche una), in un nodo, in un sistema, per garantire di gestire gli oggetti di cui abbiamo bisogno. Inoltre la gestione non è a carico del cliente, quindi se un cliente chiede ad una factory una certa Reti di Calcolatori LM 211

13 interfaccia, se esiste già un oggetto per quell'interfaccia, non avviene nessuna creazione; si nota quindi che una factory non deve sempre creare degli oggetti se gli oggetti esistano già (c'è una forte idea di condivisione). Ovviamente, la factory può lavorare solamente con ciò che conosce! 32 Per quanto riguarda l'interfaccia IClassFctory, il suo metodo fondamentale è la CreateInstance, che come già detto non è una create vera e propria, in quanto se gli venisse chiesto di creare un oggetto già esistente non andrebbe a crearlo realmente ma passerebbe al cliente che ha fatto la richiesta, il puntatore a tale oggetto; se invece l'oggetto richiesto non esistesse verrebbe creato ex-novo. Pertanto la IClassFctory è composta da due metodi: CreateInstance: che prende in ingresso un indicazione di una GUID che è il riferimento all'interfaccia che ci interessa dice un po' di specificità circa il poutercomponent, nel caso in cui l'oggetto fosse nell'ambito di un altro oggetto un parametro di output che rappresenta un puntatore all'oggetto che ci interessa Pertanto se le cose vanno bene otteniamo in quest'ultimo il riferimento alla VMT, in quanto gli oggetti sono ottenuti tramite proprio il riferimento alla VMT, ed in particolare in quest'ultimo l'interfaccia che stiamo chiedendo in un certo istante. LookServer: è una specificità dell'interfaccia delle factory che consente alle factory stesse di stare in memoria anche se non fossero riferite, quindi anche se il reference counting arrivasse a zero. In particolare: 33 Con IClassFctory2, Microsoft, prevede che, prima di creare un oggetto e metterlo a disposizione del cliente, bisogna che quest'ultimo sia possessore della licenza corretta per l'oggetto; pertanto in questa versione denominata IClassFctory2 vi è un metodo che si chiama RequestLicKey. 34 Dato che le cose sono abbastanza complicate, tipicamente vengono racchiuse in una serie di API, 212 Stefano Di Monte

14 quindi chi vuole partecipare ad una sessione COM deve all'inizio fare una BUILD per ottenere effettivamente i servizi, deve fare una INITIALIZE del COMObj con la quale si inizializza il sistema per entrare nel sistema stesso (d'altra parte farà una UNIINITIALIZE per scaricarmi dal supporto COM e rilasciare tutte le risorse), e poi, in generale, per evitare di dover conoscere tutti i dettagli (andare dalla factory, chiedere il riferimento ad un interfaccia e poi usarlo), esiste un unica funzione utilizzata tipicamente per quei clienti che vogliono attivare un oggetto, ossia la CoCreateInstance, con la quale si nasconde quindi il passaggio esplicito attraverso la factory. Quest'ultima è stata sempre molto usata! <<Come si fa a capire se l'oggetto che stiamo richiedendo è già attivo o meno?>> Tipicamente, questa funzione va, se lavoriamo a livello locale, sul registry in cui sono registrate tutte le UUID dei servitori disponibili, nel caso in cui il servitore sia da attivare allora ritroviamo il path attraverso il quale attivare il programma corrispondente: tutto ciò fortunatamente è nascosto da un po' di funzioni. IMPORTANTE: In realtà, le cose dette non sono tutte vere: la CoCreateInstance funziona in modo generale: può lavorare sia in locale che in remoto, usando, in particolare, l'informazione di contesto presente nei suoi parametri, per cercare l'informazione richiesta su un altro nodo diverso da quello locale! RICORDA: La gestione COM è una gestione complicata! 35 L'ObjRef, il riferimento all'oggetto, è in Microsoft un entità assolutamente non persistente e non permanente: è un' entità che ha senso solo per l'esecuzione corrente, non si può salvare perché in effetti è un riferimento assolutamente a run-time e non è fatto per essere salvato ed essere eventualmente riutilizzato in altre sessioni. La differenza con CORBA quindi sta nel fatto che se abbiamo un riferimento ad un oggetto e lo abbiamo salvato in una stringa, ciò vuol dire che il contratto c'è ed è un contratto permanente, in COM no: se un applicazione ha bisogno di riferimenti ad oggetti se li deve creare tutti. Tutto ciò è abbastanza pervasivo: tutti i riferimenti, ObjRef per CORBA, o come si chiamano in Microsoft, ObjectPtr non sono persistenti! In sostanza ogni applicazione, quando è il caso, deve creare i propri oggetti, e su questi creare gli ObjRef ossia gli ObjectPtr. Tutto ciò è piuttosto pesante e limitante dal punto di vista dell'operatività: molto spesso gli oggetti di Microsoft richiedono tutta una serie di altri oggetti delegati, contenuti, insomma abbastanza complessi; pertanto avere un ObjPtr da solo potrebbe non essere sufficiente perché potrebbe essere collegato ad una serie di altri ObjPtr che fanno parte, magari, di una grafo di oggetti delegati ed aggregati e dei quali ne ho bisogno per far funzionare bene le cose! Quindi per un povero gestore il tutto diventa abbastanza complesso perché deve avere conoscenza di tutte queste catene, grafi degli oggetti corrispondenti Reti di Calcolatori LM 213

15 Microsoft comincia quindi ad introdurre degli oggetti che dovrebbero nascondere alcuni problemi, ad esempio definisce delle nuove entità: i Moniker. Supponiamo di dover avere un grafo di oggetti complesso, ovviamente ciò che dovrebbe fare il bravo programmatore/gestore è attivare gli oggetti uno dopo l'altro, magari partendo da quelli contenuti (se ci sono); ovviamente quindi, chiunque deve attivare ed usare un oggetto di questo tipo, deve attivare tutto il grafo: cosa piuttosto complessa! Ed è qui che entrano in gioco i Moniker: se si riuscisse difatti, a far entrare le specifiche del grafo di oggetti in uno di questi moniker, e se fosse possibile che sia proprio il moniker a pensare all'attivazione dell'intero grafo di oggetti, il tutto si semplificherebbe di tanto, perché nasconderebbe la natura degli oggetti! Ed è proprio ciò che avviene! Difatti i moniker sono degli oggetti che possono diventare persistenti, quindi salvabili su disco, e che quando invocati sono capaci di attivare tutti gli oggetti complessi che possono portare all'esistenza necessaria di un entità che stiamo riferendo. Ad esempio, si potrebbe avere un Item Moniker, ossia un moniker capace di attivare tutti gli oggetti che hanno l'interfaccia di cui ce n'è bisogno per avere un grafo complesso, oppure File Moniker, o anche un URL Moniker ecc ecc (vedi tabella sottostante). NOTA: i moniker rappresentano una parte importante del sistema di nomi, e vennero introdotti perché altrimenti la programmazione in COM sarebbe diventata ingestibile e la fascia di competenza si sarebbe ristretta (difatti vengono un po' dopo...). 38 Tornando al filone principale, ossia alla parte di comunicazione... Come già detto: COM è un standard multi-linguaggio che consente ad un oggetto-cliente di richiedere funzionalità che un oggetto-servitore può fornire, tramite un riferimento all'oggetto. Ciò che consente di fare COM, è usare il servitore più adatto per l'interfaccia e quindi il servizio che sto chiedendo, e naturalmente voglio avere la stessa interfaccia in qualsiasi modo stia lavorando, sia se lavoro in remoto piuttosto che in locale, sia in modo non ottimizzato che ottimizzato. In sostanza quindi, il meccanismo di accesso con un ObjPtr ad un oggetto remoto o no, è lo stesso e mi nasconde il tipo di server utilizzato. In particolare esistono tre modelli di server differenti: 214 Stefano Di Monte

16 1. In-process server é uno schema in cui, in generale, l'obiettivo finale è quello di lavorare con le DLL. Si lavora in-process, quindi nell'ambito del processo stesso, proprio perché è il processo del cliente che incorpora la DLL. Out-of-process server: 2. Local server in tal caso, si ha un processo servitore sulla stessa macchina del richiedente, al quale si effettuano le richieste. Lavorare in tal modo, ovviamente si assume che l'architettura sia la stessa, quindi alcune funzionalità che, tipicamente in remoto dovrebbe implementare, ad esempio in modo molto separato, in questo contesto possono essere chiaramente abbreviate (ad esempio, se avessi dei parametri, questi potrebbero esser messi in memoria e così, sia il cliente che il servitore potrebbero vederli). 3. Remote server il servitore è situato su di un altra macchina, pertanto vi è un nodo cliente ed un nodo servitore. In generale, COM nasconde tutto ciò! Resta comunque che COM ottimizza la comunicazione in base a quale dei tre contesti si stia facendo riferimento (in CORBA questa ottimizzazione non c'è). In generale, e ciò vale per tutti e tre i casi, se l'oggetto servitore (DLL o remoto che sia) non fosse attivo, starebbe alla factory attivare il server corrispondente per ottenere l'effetto di richiesta e ottenimento del risultato della richiesta. 39 Per quanto riguarda la modalità in-process server: Ovviamente le DLL sono tutte descritte da un interfaccia che consente di gestire le DLL al meglio. In sostanza ogni qual volta che si dovrà lavorare con una DLL, la factory attiverà la DLL corrispondente se non c'è già attivata, altrimenti avremo direttamente il puntatore al suo codice. IMPORTANTE: imparare a memoria le funzioni standard delle DLL!!!!! (vedi slide). Reti di Calcolatori LM 215

17 40 In generale chi nasconde le DLL è una specie di contenitore che si chiama COMOBJ, una specie di oggetto che realizza COM, il quale si prende quindi la CoCreateInstance per le cose locali, va sulla factory, crea la DLL se non c'è, altrimenti se c'è già mi dirige sulla DLL che c'è già, ed a questo punto mi nasconde il riferimento che poi andrò a prendere. Tutte queste funzioni di supporto sono fondamentali, pertanto l'utente doveva conoscere bene la CoCreateInstance e le funzionalità di COMOBJ che sono simili in sostanza alla CoCreateInstance, per ottenere l'effetto voluto. 41 La figura qui presente dice ciò che abbiamo appena detto, circa le DLL, quindi quando si lavora in locale: io voglio ottenere una certa interfaccia, e tale interfaccia viene trovata localmente nel registry, in cui è registrata ed è associata ad una DLL, a questo punto, capito che è una DLL, vi è in sostanza una factory per le DLL, quindi viene attivata o cercata (se già attiva) tale DLL, che infine verrà riferita. 42 Per quanto riguarda le chiamate local e remote server: Quando si lavora tra processi invece, si avrà pertanto un processo cliente ed un processo servitore. Supponendo che il servitore esista, tralasciando quindi chi lo ha attivato, lavorando a questo modo, l'interazione tra i due non è diretta ma è mediata da due entità, una dalla parte del cliente (proxy) e l'altra dalla parte del servitore (stub). Quindi dalla parte del cliente ogni qual volta che vogliamo effettuare un'interazione che non è inprocess abbiam bisogno di un proxy, così come dalla parte del servitore Abbiamo bisogno di uno stub; queste due entità intermedie sono generate staticamente! Chiaramente, se un server ha 100 interfacce ha anche 100 stub, così come se un cliente deve 216 Stefano Di Monte

18 richiedere 100 interfacce dovrà avere anche 100 proxy! E dato che i componenti di COM sono multi-interfaccia, tipicamente devono gestire molte richieste e generare molti servizi. Naturalmente si parla sempre di sistema multi-linguaggio pertanto il proxy del cliente e lo stub del servitore possono essere stati prodotti in linguaggi differenti. 43 Microsoft definisce un linguaggio IDL che prende il nome di Microsoft IDL (MIDL). In realtà, quello che è stato scelto da Microsoft è usare un IDL già esistente, che rappresenta un architettura molto vicina a Microsoft, ma standard aperta ed è la DCE della OSF, e che definisce come si possono descrivere i servizi (solo questi!, quindi in realtà è un IDL che consente di definire solo delle firme di metodi). Il vantaggio di MIDL è che è compatibile con tutti i processi OLE di Microsoft perché incorpora un meccanismo precedente, ossia ODL (Object Definition Lenguage)! 44 La generazione dei proxy e degli stub rappresentava un collo di bottiglia, in quanto il sistema, con la generazione di molti proxy/stub diventava sempre più stretto in termini di memoria, di occupazione della memoria e sua gestione, ecc ecc. 45 Microsoft ha un processo molto virtuoso nella comunicazione. In sostanza, se ci fosse un servizio locale, quindi una DLL, useremmo questo, altrimenti in seconda battuta andiamo a cercare un processo locale che richiede una comunicazione locale, infine se neanche questo fosse presente, ricorreremmo a qualcosa situato su di una altro nodo. In generale, quando lavoriamo con un altro processo, tipicamente la comunicazione è mediata non solo da un proxy e da uno stub, bensì, in mezzo a questi due, anche da dei canali con RPC. Quindi la comunicazione è gestita in modo sincrono con RPC! A tal punto, quando siamo in situazioni molto remote, l' RPC appena menzionato è un reale RPC, quando invece ci troviamo a comunicare sullo stesso nodo, ciò che è stato scelto è utilizzare delle RPC ottimizzate. 46 In generale, lavorando con processi diversi locali e remoti, quindi lavorando out-of-process, abbiamo sicuramente dei proxy e degli stub ma abbiamo altresì uno strumento opportuno che garantisce che tutta la disomogeneità venga gestita bene. Per ogni singolo nodo, esiste un entità che si chiama Service Control Manager (SCM) che si occupa di capire com'è il servitore, ed in base a questo di dirigere opportunamente i meccanismi di comunicazione verso le entità correte. Si noti bene che tale SCM fa in sostanza da middleware! Reti di Calcolatori LM 217

19 L'SCM è lui stesso che capisce se ci troviamo a comunicare sullo stesso nodo con un altro processo, oppure se ci troviamo a comunicare con un server residente su di un altro nodo. 47 Se lavoriamo in remoto lavoriamo a tutti gli effetti con delle RPC assolutamente standard, difatti si tratta delle RPC di DCE. Il vantaggio nell' avere un architettura standard stava nel fatto di essere in grado di gestire la sicurezza (come si vede nella figura della slide presente), effettivamente già integrata, In questo caso il proxy e lo stub dovevano essere ben presenti perché consentivano di passare dalla rappresentazione del cliente, che era in un certo ambiente di linguaggio e in una certa architettura, alla rappresentazione del server magari in un altro ambiente di linguaggio e con un altra architettura, con un conseguente trasferimento dei parametri tipicamente per valore. Riassumendo: Quindi di sotto v' è un architettura molto molto primitiva, complessa, flessibile... mentre verso l'applicazione, quindi nella comunicazione si è molto molto disciplinati: il cliente è sincrono bloccante: fa la richiesta ed ottiene una risposta. 48 Se si lavora in locale, ma sempre out-of-process, abbiam detto che si lavora con delle RPC ottimizzate, e tale meccanismo viene chiamato light RPC che sono per l'appunto in grado di fare dei trasferimenti in modo ottimizzato: in sostanza queste costano un ordine di grandezza di meno 218 Stefano Di Monte

20 rispetto alle RPC. 49 Siamo nei primi anni '90-'95, ed un grosso problema di Microsoft è il registry, che rappresenta il repository locale delle interfacce. <<Se io volessi pertanto, lavorare in remoto, come può essere possibile attivare, con la CoCreateInstance, un qualche cosa che è dall'altra parte?>> Anche perché non saprei tanto meno a che nodo rivolgermi per andare ad attivare un oggetto di cui ne ho bisogno ed eventualmente trovare l'entità corrispondente... Il sistema di nomi, il registry, è un sistema di nomi solo locale...in cui i cammini presenti sono solo dei path locali... Ed anche se i meccanismi li ho, perché i vari SCM possono tra loro coordinarsi, <<come fa un utente a dire che non vuole qualcosa di locale? O nel caso in cui non ci sia in locale, come può attivarlo da qualche altra parte?>> Microsoft, tradizionalmente introduce una sua soluzione di sistema di nomi globale che si chiama ActiveDirectory (AD, uno strumento indipendente da COM). L'AD è un sistema di nomi globale quindi, che consente di registrare una serie di entità, la loro locazione, ed eventualmente di trovare gli oggetti corrispondenti. Un' altro grosso problema per Microsoft è che l'architettura COM prevede la presenza di un sacco di proxy e stub generati staticamente prima di attivare un componente specifico! NOTA:Pertanto COM risulta essere ambientato in uno scenario estremamente complesso da capire, con un impedenza d'accesso molto elevata, ma anche uno strumento complesso da gestire perché contenente un sacco di entità!! NOTA: Non si dice la stessa cosa di CORBA, perché: 1. le interfacce sono a grana più grossa e quindi un oggetto ne implementa solo una (o poco di più) pertanto il numero di stub e skeleton è molto limitato. Reti di Calcolatori LM 219