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

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

Dettagli

uomo Software (sistema operativo) hardware

uomo Software (sistema operativo) hardware uomo Software (sistema operativo) hardware 1 Sistema operativo Insieme di programmi che svolgono funzioni essenziali per l uso del sistema di elaborazione Questi programmi sono i primi ad essere eseguiti

Dettagli

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1)

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Pagina 1 di 10 Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Nel corso della lezione precedente abbiamo analizzato le caratteristiche dell'architettura CGI.

Dettagli

Modulo 8. Strumenti di produzione Strumenti. Gli strumenti più utilizzati per produrre pagine Web sono essenzialmente due:

Modulo 8. Strumenti di produzione Strumenti. Gli strumenti più utilizzati per produrre pagine Web sono essenzialmente due: Pagina 1 di 6 Strumenti di produzione Strumenti Gli strumenti più utilizzati per produrre pagine Web sono essenzialmente due: 1. Netscape Composer, gratuito e scaricabile da netscape.org assieme al browser

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

COM & DCOM (Distributed) Component Object Mode. Valentina Del Frate Corso Di Controllo Digitale A.A. 1999/2000

COM & DCOM (Distributed) Component Object Mode. Valentina Del Frate Corso Di Controllo Digitale A.A. 1999/2000 COM & DCOM (Distributed) Component Object Mode Valentina Del Frate Corso Di Controllo Digitale A.A. 1999/2000 COM : Prima Definizione (Glossario Informatico) Una Architettura software messa a punto da

Dettagli

Come fare a leggere questi dati generati da un programma windows?

Come fare a leggere questi dati generati da un programma windows? Come fare a leggere questi dati generati da un programma windows? A questo punto siamo in possesso di tutti gli elementi per sfruttare appieno le potenzialità di Linux: sappiamo destreggiarci (mai abbastanza)

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Corso di Architetture Distribuite e Servizi di Rete. COM e DCOM,.NET. Antonio Corradi & Paolo Bellavista ARCHITETTURA COM

Corso di Architetture Distribuite e Servizi di Rete. COM e DCOM,.NET. Antonio Corradi & Paolo Bellavista ARCHITETTURA COM Università degli Studi di Bologna Facoltà di Ingegneria Corso di Architetture Distribuite e Servizi di Rete COM e DCOM,.NET Antonio Corradi & Paolo Bellavista COM e DCOM,.NET 1 ARCHITETTURA COM ARCHITETTURA

Dettagli

1.2.1.1 DEFINIZIONE DI SOFTWARE

1.2.1.1 DEFINIZIONE DI SOFTWARE Software 1.2 1.2.1.1 DEFINIZIONE DI SOFTWARE Il computer non è in grado di svolgere alcun compito autonomamente Esso può eseguire svariati compiti soltanto se viene opportunamente istruito Ciò avviene

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento

Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento Tecnologie per lo sviluppo di applicazioni La tendenza attuale dell'ingegneria è quella dell'integrazione di componenti

Dettagli

Il Software... A.A. 2013-14 Informatica 96

Il Software... A.A. 2013-14 Informatica 96 Il Software... A.A. 2013-14 Informatica 96 Il software L hardware non è direttamente utilizzabile Sono necessari dei programmi per far svolgere delle funzioni all insieme di circuiti Informatica 97 Il

Dettagli

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS 1 Tecnologia delle BD: perché studiarla? File e indici I DBMS offrono i loro servizi in modo "trasparente": per questo abbiamo potuto finora ignorare molti aspetti realizzativi abbiamo considerato il DBMS

Dettagli

Se il malfunzionamento si presenta qualunque sia il programma in esecuzione è molto probabile che il problema sia hardware e non software.

Se il malfunzionamento si presenta qualunque sia il programma in esecuzione è molto probabile che il problema sia hardware e non software. Pagina 1 di 11 Strategie e tecniche di individuazione dei malfunzionamenti Introduzione In questa sezione si cercherà di definire una metodologia per risolvere semplici problemi software che possono presentarsi

Dettagli

2 Ambiente che confina e sconfina con ambienti di business ed enterprise.

2 Ambiente che confina e sconfina con ambienti di business ed enterprise. Web Services 2 Ambiente che confina e sconfina con ambienti di business ed enterprise. Service Oriented Architecture (SOA) Soffermandoci solo alla lettura della sigla ciò che si intende è una architettura

Dettagli

19 aprile 2013. Activ1st Descrizione prodotto

19 aprile 2013. Activ1st Descrizione prodotto 19 aprile 2013 Activ1st Descrizione prodotto Le informazioni contenute in questo documento sono da considerarsi CONFIDENZIALI e non possono essere utilizzate o riprodotte - sia in parte che interamente

Dettagli

Middleware vari. L'obbiettivo quindi è quello di fornire dei servizi con qualità!

Middleware vari. L'obbiettivo quindi è quello di fornire dei servizi con qualità! Middleware vari 2 Col termine middleware si indica tutto ciò che è in mezzo tra l'utente e tutte le risorse locali di sistema operativo e di tecnologie di scelte locali. In realtà il termine middleware

Dettagli

Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto. Approfondimento SOFTWARE PER L ARCHIVIAZIONE

Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto. Approfondimento SOFTWARE PER L ARCHIVIAZIONE APPROFONDIMENTO ICT Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto Approfondimento SOFTWARE PER L ARCHIVIAZIONE ORGANISMO BILATERALE PER LA FORMAZIONE IN CAMPANIA INDICE SOFTWARE PER

Dettagli

Modulo 12. Cliente di posta elettronica Di cosa abbiamo bisogno per usare la posta elettronica?

Modulo 12. Cliente di posta elettronica Di cosa abbiamo bisogno per usare la posta elettronica? Pagina 1 di 14 Cliente di posta elettronica Di cosa abbiamo bisogno per usare la posta elettronica? L'obiettivo di questo approfondimento è imparare a configurare un cliente di posta elettronica. Come

Dettagli

Modulo 9. Sicurezza nei sistemi Unix Utenti e gruppi in Unix (1/2)

Modulo 9. Sicurezza nei sistemi Unix Utenti e gruppi in Unix (1/2) Pagina 1 di 11 Sicurezza nei sistemi Unix Utenti e gruppi in Unix (1/2) In questa lezione tratteremo di alcuni concetti di sicurezza tipici dei sistemi Unix. In particolare, questi sistemi definiscono

Dettagli

WEBGATE400 ACTIVEX CONTROL. Manuale Programmatore

WEBGATE400 ACTIVEX CONTROL. Manuale Programmatore WEBGATE400 ACTIVEX CONTROL Manuale Programmatore Pagina 1 SOMMARIO Webgate400 ActiveX Control... 3 1 A Chi è destinato... 3 2 Pre requisiti... 3 3 Introduzione... 3 3.1 Requisiti di sistema... 3 3.2 Distribuzione

Dettagli

Parte VI SISTEMI OPERATIVI

Parte VI SISTEMI OPERATIVI Parte VI SISTEMI OPERATIVI Sistema Operativo Ogni computer ha un sistema operativo necessario per eseguire gli altri programmi Il sistema operativo, fra l altro, è responsabile di riconoscere i comandi

Dettagli

Sommario della lezione

Sommario della lezione Sistemi Operativi Docente: Ugo Erra ugoerr+so@dia.unisa.it 2 LEZIONE STRUTTURE DEI SISTEMI OPERATIVI CORSO DI LAUREA TRIENNALE IN INFORMATICA UNIVERSITA DEGLI STUDI DELLA BASILICATA Sommario della lezione

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Lezione 3 Martedì 15-10-2013 1 Struttura ed organizzazione software dei sistemi

Dettagli

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache... Appunti di Calcolatori Elettronici Concetti generali sulla memoria cache Introduzione... 1 Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Dettagli

Crotone, maggio 2005. Windows. Ing. Luigi Labonia E-mail luigi.lab@libero.it

Crotone, maggio 2005. Windows. Ing. Luigi Labonia E-mail luigi.lab@libero.it Crotone, maggio 2005 Windows Ing. Luigi Labonia E-mail luigi.lab@libero.it Sistema Operativo Le funzioni software di base che permettono al computer di funzionare formano il sistema operativo. Esso consente

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Corso di Elettronica dei Sistemi Programmabili. Sistemi Operativi Real Time. Introduzione. Aprile 2014 Stefano Salvatori 1/28

Corso di Elettronica dei Sistemi Programmabili. Sistemi Operativi Real Time. Introduzione. Aprile 2014 Stefano Salvatori 1/28 Corso di Elettronica dei Sistemi Programmabili Sistemi Operativi Real Time Introduzione Aprile 2014 Stefano Salvatori 1/28 Sommario Definizioni livelli di astrazione processi di tipo batch e processi interattivi

Dettagli

Implementazione di MVC. Gabriele Pellegrinetti

Implementazione di MVC. Gabriele Pellegrinetti Implementazione di MVC Gabriele Pellegrinetti 2 Come implementare il pattern Model View Controller con le tecnologie JSP, ASP e XML Implementazione del pattern MVC in Java (JSP Model 2) SUN è stato il

Dettagli

CORSO WEB SERVER, DBMS E SERVER FTP

CORSO WEB SERVER, DBMS E SERVER FTP CORSO WEB SERVER, DBMS E SERVER FTP DISPENSA LEZIONE 1 Autore D. Mondello Transazione di dati in una richiesta di sito web Quando viene effettuata la richiesta di un sito Internet su un browser, tramite

Dettagli

L interfaccia di P.P.07

L interfaccia di P.P.07 1 L interfaccia di P.P.07 Barra Multifunzione Anteprima delle slide Corpo della Slide Qui sotto vediamo la barra multifunzione della scheda Home. Ogni barra è divisa in sezioni: la barra Home ha le sezioni

Dettagli

GEODROP APPLICATIONS. Developer. Public. Private. Reseller

GEODROP APPLICATIONS. Developer. Public. Private. Reseller GEODROP APPLICATIONS Public Developer Reseller Private Le Applicazioni di Geodrop Guida per Developer alle Applicazioni Guida alle applicazioni v1.1-it, 21 Dicembre 2012 Indice Indice...2 Cronologia delle

Dettagli

DUAL BOOT WINDOWS-LINUX.

DUAL BOOT WINDOWS-LINUX. DUAL BOOT WINDOWS-LINUX. Realizzato da Jona Lelmi Nickname PyLinx Iniziato il giorno 5 Luglio 2010 - terminato il giorno 8 Luglio 2010 email autore: jona.jona@ymail.com Canale Youtube http://www.youtube.com/user/pylinx

Dettagli

Programmazione di sistemi distribuiti

Programmazione di sistemi distribuiti Programmazione di sistemi distribuiti I Sistemi Distribuiti, per loro natura, prevedono che computazioni differenti possano essere eseguite su VM differenti, possibilmente su host differenti, comunicanti

Dettagli

Naming nei Sistemi Distribuiti

Naming nei Sistemi Distribuiti Naming nei Sistemi Distribuiti Naming (1) La risoluzione dei nomi permette ad un processo di accedere ad una entità in un sistema distribuito. Un sistema di naming è necessario per avere un modello comune

Dettagli

Naming nei Sistemi Distribuiti

Naming nei Sistemi Distribuiti Naming nei Sistemi Distribuiti Naming (1) La risoluzione dei nomi permette ad un processo di accedere ad una entità in un sistema distribuito. Un sistema di naming è necessario per avere un modello comune

Dettagli

Capitolo 1 Introduzione a Gambas

Capitolo 1 Introduzione a Gambas Capitolo 1 Introduzione a Gambas Gambas è stato creato inizialmente da Benoit Minisini, un residente della periferia di Parigi. Secondo Benoit, Gambas è un linguaggio Basic con estensioni per la programmazione

Dettagli

SISTEMI OPERATIVI. Sincronizzazione dei processi. Domande di verifica. Luca Orrù Centro Multimediale Montiferru 30/05/2007

SISTEMI OPERATIVI. Sincronizzazione dei processi. Domande di verifica. Luca Orrù Centro Multimediale Montiferru 30/05/2007 2007 SISTEMI OPERATIVI Sincronizzazione dei processi Domande di verifica Luca Orrù Centro Multimediale Montiferru 30/05/2007 Sincronizzazione dei processi 1. Si descrivano i tipi di interazione tra processi?

Dettagli

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra.

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra. Appunti di Calcolatori Elettronici Modello di macchina multilivello Introduzione... 1 Linguaggi, livelli e macchine virtuali... 3 La struttura a livelli delle macchine odierne... 4 Evoluzione delle macchine

Dettagli

Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16

Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16 Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16 Cosa vedremo Il software applicativo Categorie di SW Il sistema operativo Gestione programmi in esecuzione (processi) Gestione memoria Gestione

Dettagli

Componenti di un sistema operativo

Componenti di un sistema operativo Componenti di un sistema operativo di Daniele Margutti CONTATTI Mail: daniele@malcombsd.com AIM/iChat: malcombsd Web: http://www.malcombsd.com INDICE: 1. Nota introduttiva 2. La gestione dei processi di

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

Software per la gestione di musei di arte contemporanea1

Software per la gestione di musei di arte contemporanea1 Software per la gestione di musei di arte contemporanea1 Identificativo del progetto: CA Nome documento: System Design(SD) Identificativo del documento: 6 CA_SD_E1_R1 Data del documento: 21/05/2012 Prima

Dettagli

SMARTBOARD. Cosa si può fare con una smartboard?

SMARTBOARD. Cosa si può fare con una smartboard? SMARTBOARD Cosa si può fare con una smartboard? si può scrivere come si farebbe su una lavagna, con il vantaggio di poter poi salvare quanto scritto; si può andare ad interagire con una presentazione PowerPoint

Dettagli

Autenticazione ed integrità dei dati Firewall

Autenticazione ed integrità dei dati Firewall Pagina 1 di 9 Autenticazione ed integrità dei dati Firewall Per proteggere una rete dagli attacchi provenienti dall'esterno si utilizza normalmente un sistema denominato Firewall. Firewall è un termine

Dettagli

Vocabolario & Terminologie Informatiche

Vocabolario & Terminologie Informatiche Vocabolario & Terminologie Informatiche HARWARE: In ingegneria elettronica e informatica con il termine hardware si indica la parte fisica di un computer, ovvero tutte quelle parti elettroniche, elettriche,

Dettagli

Sistemi informatici. Informatica. Il software. Il sw di sistema. Il sw applicativo. Il sw di sistema. Il sistema operativo. Hardware.

Sistemi informatici. Informatica. Il software. Il sw di sistema. Il sw applicativo. Il sw di sistema. Il sistema operativo. Hardware. http://159.149.98.238/lanzavecchia/docum enti/sscta.htm Sistemi informatici Hardware Microprocessore Memoria Periferiche di input e output Software Software di sistema Programmi applicativi 1 2 Il sw applicativo

Dettagli

Visual basic base Lezione 01. L'ambiente di sviluppo

Visual basic base Lezione 01. L'ambiente di sviluppo L'ambiente di sviluppo L'ambiente di sviluppo Visual basic è un linguaggio di programmazione Microsoft. In questo corso prenderemo in considerazione, l'ultima versione. net di questo linguaggio. Microsoft

Dettagli

1. I FONDAMENTI DELLA PROGRAMMAZIONE AD OGGETTI

1. I FONDAMENTI DELLA PROGRAMMAZIONE AD OGGETTI IL LINGUAGGIO JAVA Dispense per il corso di laboratorio di sistemi I.T.I.S. ABACUS A.S. 2008/2009 Autore: Roberto Amadini Testo di riferimento: La programmazione ad oggetti C++ Java (Lorenzi, Moriggia,

Dettagli

Word. Unità didattica 1 - Concetti generali

Word. Unità didattica 1 - Concetti generali Word Unità didattica 1 - Concetti generali Prerequisiti: nessuno in particolare Obiettivi: aprire, chiudere Word salvare un documento utilizzare la guida in linea modificare impostazioni di base Avviare

Dettagli

INFORMATICA. Il Sistema Operativo. di Roberta Molinari

INFORMATICA. Il Sistema Operativo. di Roberta Molinari INFORMATICA Il Sistema Operativo di Roberta Molinari Il Sistema Operativo un po di definizioni Elaborazione: trattamento di di informazioni acquisite dall esterno per per restituire un un risultato Processore:

Dettagli

CORBA & DCOM. Gianpaolo Cugola cugola@elet.polimi.it http://www.elet.polimi.it/~cugola. La Object Management Architecture

CORBA & DCOM. Gianpaolo Cugola cugola@elet.polimi.it http://www.elet.polimi.it/~cugola. La Object Management Architecture CORBA & DCOM Gianpaolo Cugola cugola@elet.polimi.it http://www.elet.polimi.it/~cugola Sommario La Object Management Architecture CORBA La programmazione di applicazioni CORBA in Java CORBA vs. RMI DCOM

Dettagli

CdL MAGISTRALE in INFORMATICA

CdL MAGISTRALE in INFORMATICA 05/11/14 CdL MAGISTRALE in INFORMATICA A.A. 2014-2015 corso di SISTEMI DISTRIBUITI 7. I processi : il naming Prof. S.Pizzutilo Il naming dei processi Nome = stringa di bit o di caratteri utilizzata per

Dettagli

Getting started. Creare una semplice applicazione con supporto OPC Client

Getting started. Creare una semplice applicazione con supporto OPC Client Getting started Creare una semplice applicazione con supporto OPC Client Revisioni del documento Data Edizione Commenti 25/11/2009 1.0-25/11/2009 1.0 - Sielco Sistemi srl via Roma, 24 I-22070 Guanzate

Dettagli

Manuale d'uso. e.compliance. Versione 0.5

Manuale d'uso. e.compliance. Versione 0.5 Manuale d'uso e.compliance Versione 0.5 31/12/2007 1 Indice generale Scopo del manuale...5 e.toscana Compliance...6 Introduzione...7 I documenti Request For Comments (RFC) e.toscana...7 Tipologie di RFC...7

Dettagli

Approccio stratificato

Approccio stratificato Approccio stratificato Il sistema operativo è suddiviso in strati (livelli), ciascuno costruito sopra quelli inferiori. Il livello più basso (strato 0) è l hardware, il più alto (strato N) è l interfaccia

Dettagli

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA CORBA ( Common Object Request Broker Architecture ) consiste in un insieme di specifiche promosse e curate da OMG (Object Management Group). L OMG è un consorzio internazionale no-profit di industrie nel

Dettagli

Indice degli argomenti del s.o. Software. Software. Buona lezione a tutti!! SISTEMI OPERATIVI

Indice degli argomenti del s.o. Software. Software. Buona lezione a tutti!! SISTEMI OPERATIVI Buona lezione a tutti!! SISTEMI OPERATIVI Gli appunti sono disponibili per tutti gratis sul sito personale del Prof M. Simone al link: www.ascuoladi.135.it nella pagina web programmazione, sezione classi

Dettagli

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente:

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il.NET Framework By Dario Maggiari L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il cuore del.net Framework è costituito dal CLR (Common Language Runtime) che, secondo

Dettagli

PRONTE AI POSTI VIA! LE 4 CHIAVI DI UN BUSINESS DI CUI ESSERE... MODULO 3

PRONTE AI POSTI VIA! LE 4 CHIAVI DI UN BUSINESS DI CUI ESSERE... MODULO 3 PRONTE AI POSTI VIA! LE 4 CHIAVI DI UN BUSINESS DI CUI ESSERE... pazza! MODULO 3 Fino ad ora abbiamo lavorato sulla consapevolezza, identificando le 4 chiavi che ci servono per aver successo nel nostro

Dettagli

Introduzione al sistema operativo Il file system: file, directory,...

Introduzione al sistema operativo Il file system: file, directory,... ,OVRIWZDUHGLVLVWHPD cosa vedremo: Introduzione al sistema operativo Il file system: file, directory,...... 223,OVRIWZDUHLQWURGX]LRQH L hardware da solo non è sufficiente per il funzionamento dell elaboratore

Dettagli

Informatica e Bioinformatica: Sistemi Operativi

Informatica e Bioinformatica: Sistemi Operativi Informatica e Bioinformatica: Sistemi Operativi 11 marzo 2013 Macchina Hardware/Software Sistema Operativo Macchina Hardware La macchina hardware corrisponde alle componenti fisiche del calcolatore (quelle

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Fondamenti di Informatica

Fondamenti di Informatica Fondamenti di Informatica Il software Dipartimento di Ingegneria dell Informazione Universitàdegli Studi di Parma SOFTWARE I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono

Dettagli

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Distributed Object Computing

Distributed Object Computing Evoluzione Architetturale Distributed omputing entralizzata Monolitica anni 60-70 Reti locali di P anni 80 Reti lient Server anni 80-90 Internet The network is the computer Paolo Falcarin Sistemi Informativi

Dettagli

Elementi del calcolatore: CPU

Elementi del calcolatore: CPU Elementi del calcolatore: CPU Elementi del calcolatore: Memoria Elementi del calcolatore: Memoria Elementi del calcolatore: Hard Disk Antefatto Sistema Operativo Come il computer appare Il calcolatore

Dettagli

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI Il Software Software di Base Sistema Operativo (Software di base essenziale) Software di base non essenziale Utility Driver Software applicativi (Applicazioni)

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Guida alla composizione di modelli OpenOffice

Guida alla composizione di modelli OpenOffice Tekne Informatica & Comunicazione Guida alla composizione di modelli OpenOffice guida rapida per creare e modificare modelli OpenOffice per XDent 01 aprile 2011 Sommario Premessa... 2 Ottenere ed Installare

Dettagli

HORIZON SQL CONFIGURAZIONE DI RETE

HORIZON SQL CONFIGURAZIONE DI RETE 1-1/9 HORIZON SQL CONFIGURAZIONE DI RETE 1 CARATTERISTICHE DI UN DATABASE SQL...1-2 Considerazioni generali... 1-2 Concetto di Server... 1-2 Concetto di Client... 1-2 Concetto di database SQL... 1-2 Vantaggi...

Dettagli

Indice. settembre 2008 Il File System 2

Indice. settembre 2008 Il File System 2 Il File System Indice 4. Il File System 5. Vantaggi del FS 6. Protezione 7. Condivisione 8. I file - 1 9. I file - 2 10. Attributi dei file 11. Directory 12. Livelli di astrazione - 1 13. Livelli di astrazione

Dettagli

Intel Server Management Pack per Windows

Intel Server Management Pack per Windows Intel Server Management Pack per Windows Manuale dell'utente Revisione 1.0 Dichiarazioni legali LE INFORMAZIONI CONTENUTE IN QUESTO DOCUMENTO SONO FORNITE IN ABBINAMENTO AI PRODOTTI INTEL ALLO SCOPO DI

Dettagli

DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0

DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0 DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0 nelle lezioni precedenti abbiamo preso in esame tutte le caratteristiche e le funzionalità del microprocessore didattico

Dettagli

Procedura di installazione e configurazione per l'applicazione. SchedeCet

Procedura di installazione e configurazione per l'applicazione. SchedeCet Procedura di installazione e configurazione per l'applicazione SchedeCet usata per l'immissione delle schede utenti dei Centri Ascolto Caritas della Toscana. Questo documento è destinato agli operatori

Dettagli

www.informarsi.net MODULO 6 ECDL - EIPASS STRUMENTI DI PRESENTAZIONE - PRESENTATIONS Microsoft PowerPoint http://www.informarsi.net/ecdl/powerpoint/

www.informarsi.net MODULO 6 ECDL - EIPASS STRUMENTI DI PRESENTAZIONE - PRESENTATIONS Microsoft PowerPoint http://www.informarsi.net/ecdl/powerpoint/ MODULO 6 ECDL - EIPASS STRUMENTI DI PRESENTAZIONE - PRESENTATIONS Microsoft PowerPoint http:///ecdl/powerpoint/ INTERFACCIA UTENTE TIPICA DI UN SOFTWARE DI PRESENTAZIONE APERTURA E SALVATAGGIO DI UNA PRESENTAZIONE

Dettagli

Altre due categorie non rientrano né nel software di sistema, né in quello applicativo pur contenendo elementi tipici di entrambi sono:

Altre due categorie non rientrano né nel software di sistema, né in quello applicativo pur contenendo elementi tipici di entrambi sono: 3. Il Software TIPI DI SOFTWARE La macchina come insieme di componenti hardware di per sé non è in grado di funzionare. Sono necessari dei programmi progettati dall uomo che indicano la sequenza di istruzioni

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

Access - Lezione 02. Basi di dati. Parte seconda. (Per andare direttamente su un argomento, fare clic con il mouse sul titolo nell indice sottostante)

Access - Lezione 02. Basi di dati. Parte seconda. (Per andare direttamente su un argomento, fare clic con il mouse sul titolo nell indice sottostante) Access - Lezione 02 Basi di dati Parte seconda (Per andare direttamente su un argomento, fare clic con il mouse sul titolo nell indice sottostante) 1.0 Operazioni di base 1.1 Impostare e pianificare un

Dettagli

Corso di Reti di Calcolatori LS

Corso di Reti di Calcolatori LS Università degli Studi di Bologna Facoltà di Ingegneria Corso di Reti di Calcolatori LS CORBA - Implementazione Naming Service e Interface Repository Luca Foschini Anno accademico 2008/2009 Agenda CORBA

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

10. Interfaccia del File System

10. Interfaccia del File System 10. Interfaccia del File System 10.1 Il concetto di File 10.2 Metodi di accesso 10.3 Struttura delle Directory 10.4 Protezione (Leggere) 10.5 Semantica della Consistenza (Leggere) Un File System consiste

Dettagli

Sistemi operativi e Microsoft Windows

Sistemi operativi e Microsoft Windows Sistemi operativi e Microsoft Windows Sistemi operativi e Microsoft Windows...1 Definizioni di carattere generale...2 Interfaccia...2 Interfaccia Utente...2 Sistema operativo...2 CPU (Central Processing

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

RMI Remote Method Invocation

RMI Remote Method Invocation RMI Remote Method Invocation [Pagina intenzionalmente vuota] (1 12 2004) slide 4:1/18 (p.106) Un applicazione RMI è un applicazione distribuita ad oggetti. Applicazione RMI tipica, strutturata in: server:

Dettagli

INTERFACCIA UTENTE----------------------------------------------------------------------------------------------------

INTERFACCIA UTENTE---------------------------------------------------------------------------------------------------- IL FILE SYSTEM PROF. ANTONIO TUFANO Indice 1 FILE SYSTEM ------------------------------------------------------------------------------------------------------------------ 3 1.1. CARATTERISTICHE E STORIA

Dettagli

Sommario. G. Piscitelli

Sommario. G. Piscitelli Sommario Interprocess Communication Processi (e thread) cooperanti Il paradigma produttore-consumatore Shared Memory e Inter Process Communication (IPC) facility Proprietà caratteristiche della comunicazione

Dettagli

Il software. Il Sistema Operativo

Il software. Il Sistema Operativo Il software Prof. Vincenzo Auletta 1 Il Sistema Operativo Software che gestisce e controlla automaticamente le risorse del computer permettendone il funzionamento. Gestisce il computer senza che l utente

Dettagli

Architetture software

Architetture software Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architettura software 1 Architetture software Sommario Definizioni 2 Architettura Definizione. L architettura

Dettagli

Architetture basate su componenti

Architetture basate su componenti Luca Cabibbo Architetture Software Architetture basate su componenti Dispensa ASW 440 ottobre 2014 Affida le cose speciali agli specialisti. Robert Spinrad 1 -Fonti [POSA4] Pattern-Oriented Software Architecture

Dettagli

Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto. Approfondimento INTERNET: IL FUNZIONAMENTO DELL INFRASTRUTTURA E DELLA RETE

Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto. Approfondimento INTERNET: IL FUNZIONAMENTO DELL INFRASTRUTTURA E DELLA RETE APPROFONDIMENTO ICT Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto Approfondimento INTERNET: IL FUNZIONAMENTO DELL INFRASTRUTTURA E DELLA RETE ORGANISMO BILATERALE PER LA FORMAZIONE

Dettagli

Guida all'amministrazione. BlackBerry Professional Software per Microsoft Exchange. Versione: 4.1 Service Pack: 4

Guida all'amministrazione. BlackBerry Professional Software per Microsoft Exchange. Versione: 4.1 Service Pack: 4 BlackBerry Professional Software per Microsoft Exchange Versione: 4.1 Service Pack: 4 SWD-313211-0911044452-004 Indice 1 Gestione degli account utente... 7 Aggiunta di un account utente... 7 Aggiunta manuale

Dettagli

App-V Dynamic Suite Composition

App-V Dynamic Suite Composition App-V Dynamic Suite Composition di Nicola Ferrini MCT MCSA MCSE MCTS MCITP Introduzione Con Microsoft Application Virtualization 4.5 è possibile utilizzare la Dynamic Suite Composition, cioè definire un

Dettagli

Ambienti di programmazione.net Lezione n. 1

Ambienti di programmazione.net Lezione n. 1 Il Framework Redistribuitable Package e il Framework Sdk (Software Development Kit) 1.1 Italian Presentazione del corso Con l avvento della piattaforma applicativa.net Microsoft è riuscita a portare un

Dettagli

L'elaborazione dei dati su client Linguaggi di script

L'elaborazione dei dati su client Linguaggi di script Pagina 1 di 5 L'elaborazione dei dati su client Linguaggi di script Attualmente si tende a scaricare sul computer dell'utente piccoli programmi (Javascript o applet Java) che svolgano parte dell'elaborazione

Dettagli