Un Architettura per il Monitoraggio on-line della Java Virtual Machine

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Un Architettura per il Monitoraggio on-line della Java Virtual Machine"

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Tesi di laurea Un Architettura per il Monitoraggio on-line Anno Accademico 2005/2006 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Salvatore Orlando candidato Rinaldi Ciro matr. 534/926

2 Dedica Alla mia Famiglia. La scienza è fatta di dati come una casa di pietre. Ma un ammasso di dati non è scienza più di quanto un mucchio di pietre sia una casa. -Jules Henri Poincaré

3 Indice 1 La Java Virtual Machine, il Problema dell' Adabilità Introduzione L'Architettura Il ClassLoader La Gestione della Memoria Heap, la Garbage Collection Principali Algoritmi di Garbage Collection La Java Virtual Machine ed il Compilatore HotSpot Java Threads Execution Engine Error Handling Classicazione dei Fallimenti Conclusioni Il Problema del Monitoraggio nel Contesto della Java Virtual Machine Metodologie per lo Studio di Adabilità Measured-based Analysis Dependability Benchmarking Error Injection Robustness Testing Aging Analysis iii

4 2.2 Tecniche e Tecnologie per il Monitoraggio Java Virtual Machine Tool Interface Java Management extensions Bytecode Injection Tools di Monitoraggio ej-technologies, JProler Sun Microsystems, HPROF: Heap Proler Conclusioni JVMMon: Un Sistema di Monitoraggio Orientato alla Diagnosi Introduzione a JVMMon Funzionalità Oerte Architettura JVMTI Agent Local Monitor Daemon Data Collector Soluzioni di Design Descrizione dell' Agente JVMTI Instrumentation Tool, (Agente Java) Communication Layer Valutazione Sperimentale Obiettivo delle Misure Testbed Utilizzato Risultati Conclusioni Appendice 60 A 60 iv

5 Elenco delle gure 1.1 Fasi del Class Loading Execution Engine Fault Classication Analisi dei Fallimenti del Tandem System Dependability Scenario Virtual Machine JMX Tiered Architecture Trasformazione di classi a Load Time Esempi di funzionamento di JProler Java Virtual Machine Heap Architettura di JVMMon Evoluzione dello Stato della Virtual Machine Object Hot Swapping Overhead introdotto da JVMmon Performance Overhead, comparativa tra JVMMon ed HPROF Memory Footprint Comparison v

6 Elenco delle tabelle 3.1 Formato del Local Log File dell'agente JVMTI vi

7 Capitolo 1 La Java Virtual Machine, il Problema dell' Adabilità 1.1 Introduzione E' indubbio che la piattaforma Java, negli ultimi anni, è divenuta sempre più utilizzata, anche in scenari profondamente diversi, grazie soprattutto, ad alcune su caratteristiche peculiari quali: l'alto livello di portabilità, le astrazioni di programmazione ed in generale, grazie alle migliorie ed evoluzioni della piattaforma stessa. Attualmente non è dicile riscontrare l'uso della piattaforma nell'ambito di applicazioni cosidette critiche, come sistemi Real Time, applicazioni transazionali, i sistemi di controllo remoto. Tuttavia la JVM non possiede (almeno nelle attuali implementazioni) nessun supporto diretto alla Fault Tolerance. Per poter sviluppare dei sistemi capaci di essere tolleranti ai guasti, è necessario riuscire ad interpretare il comportamento della con riferimento agli errori ed ai fallimenti che si manifestano. Questa analisi, presentata successivamente, ci ha permesso di ssare dei focus, su cui focalizzare l'attenzione, nello sviluppo di una unità di monitoraggio della JVM; lo sviluppo di tale monitor, è da considerarsi come un primo passo 1

8 verso la progettazione di una JVM in grado di tollerare un buon numero di situazioni anomale, di gestirle, e quindi di proseguire nelle sue attività senza andare in crash, o comunque, in un qualsisi stato in cui l'adabilità dei risultati dell'elaborazione della stessa siano inattendibili oppure, addirittura, completamente errati. 2

9 1.2 L'Architettura Il ClassLoader Figura 1.1: Fasi del Class Loading Il sottosistema, incaricato di cercare e caricare i tipi, è il Class Loader Subsystem. La Java Virtual Machine comprende due tipi di Class Loaders: un Bootstrap Class Loader e gli User Dened Class Loaders; Il primo, è parte dell'implementazione della JVM, gli User Dened, invece, sono parte dell' applicazione Java in esecuzione. In realtà va chiarito che, oltre a localizzare ed importare i dati binari per le classi, i Class Loader sono anche responsabili di vericare la correttezza delle classi importate, di allocare ed inizializzare la memoria per le variabili delle classi ed inoltre partecipano a risolvere i riferimenti simbolici; in particolare è possibile identicare queste tre fasi del processo di Class Loading 1.1: 1. Loading: vengono localizzati ed importati i dati binari di una classe. 2. Linking: Verica: ci si assicura della correttezza del tipo importato; 3

10 Preparazione: si alloca memoria per le variabili della classe e la si inizializza ai valori di default; Risoluzione: si trasformano i riferimenti simbolici in riferimenti diretti; 3. Initialization: viene invocato il codice Java che inizializza le variabili della classe ai valori iniziali La Gestione della Memoria Heap, la Garbage Collection Il processo della Garbage Collection comporta la liberazione delle risorse utilizzate da oggetti non più referenziati dall'applicazione in esecuzione. La specica Java non impone, nella scelta delle tecniche e degli algoritmi di Garbage Collection, alcun vincolo. Il Garbage Collector deve, in qualche modo, determinare quali oggetti non sono più referenziati da una applicazione e rendere riutilizzabile lo spazio, della memoria heap, occupato dai suddetti oggetti. Tra l'altro, compito del Garbage Collector è quello di combattere il fenomeno della frammentazione dell'area heap. Esistono, chiaramente, una serie di vantaggi indiscussi sfruttando un approccio gestito della memoria; tra questi sicuramente possiamo annoverare l'incremento di produttività e la salvaguardia automatica della memoria, evitando così crash accidentali derivanti da una erronea gestione delle risorse da liberare. In contrapposizione ai suddetti vantaggi, vanno segnalati anche alcune problematiche che emergono nella gestione automatica della memoria: bisogna tener conto dell'overhead introdotto dal dover iterare costantemente l'albero dei riferimenti degli oggetti; l'aleatorietà con cui il processo di Garbage Collection viene schedulato [10]. 4

11 Ogni Garbage Collector deve fondamentalmente eseguire due mansioni: Riconoscere gli oggetti da segnalare per la Garbage Collection. Liberare spazio nell'area Heap. La Garbage Detection tipicamente è eettuata denendo un set di root references e determinando la reachability (raggiungibilità) dai roots; un oggetto è raggiungibile se esiste almeno un percorso, attraverso i references, dai roots attraverso cui è accedibile da un programma in esecuzione. Tutti gli oggetti che sono accedibili dai roots sono considerati live, altrimenti Garbage. 5

12 1.2.3 Principali Algoritmi di Garbage Collection Reference Counting : è stata la prima strategia di Garbage Collection implementata nella Hot Spot. In questo approccio, un contatore, detto reference count, è mantenuto per ogni oggetto presente nell'heap. Quando un oggetto viene creato ed un riferimento ad esso viene assegnato ad una variabile, il counter dell'oggetto viene settato ad uno. Quando un'altra variabile assegna un riferimento a quell'oggetto, il contatore dell'oggetto viene incrementato; se invece un riferimento ad un oggetto esce dall'ambito della visibilità oppure è assegnato un nuovo valore, il contatore viene decrementato. Ogni oggetto, il cui contatore è settato al valore zero, viene segnalato per la garbage collection. La semplicità di implementazione di questa tecnica si scontra con il difetto di non riuscire ad identicare i cicli di riferimenti, ad esempio: Tracing Collectors: investiga il grafo dei riferimenti agli oggetti iniziando dai nodi roots; gli oggetti, a mano a mano che vengono ispezionati, sono marcati settando un ag (direttamente nell'oggetto oppure attraverso una bitmap). Quando il tracing è completo, gli oggetti privi del ag sono segnalati come unreachable e possono essere garbage collected. Compacting Collectors: I Garbage Collectors dovrebbero, tra l'altro, tentare di combattere il fenomeno della frammentazione dell'area Heap, problema comune alle MMU (Memory Management Unit) dei sistemi operativi. Due delle strategie maggiormente in voga sono la compattazione e la copia. Entrambe le tecniche spostano oggetti on the y per ridurre la frammentazione dell'heap. I Compacting Collectors spostano gli oggetti in stato live attraverso lo spazio libero nell'heap no alla ne; i riferimenti degli oggetti spostati vengono poi aggiornati. Uno modo per semplicare l'aggiornamento dei references è quello di aggiungere un livello di indirizzamento indiretto. Copying Collectors: questi collectors invece, spostano tutti gli oggetti, in stato live, in una nuova area e li pongono spalla a spalla eliminando la 6

13 frammentazione della suddetta area; la area precedentemente occupata viene segnalata come libera. Una tecnica abbastanza comune, tra i Copying Collectors, è la Stop And Copy. In questo approccio l'area heap viene divisa in due regioni, di queste, se ne utilizza solo una alla volta. Quando lo spazio di quella in uso termina, l'esecuzione del programma viene messa in stop, tutti gli oggetti della prima regione vengono travasati nella seconda side by side. Al termine della copia viene ripresa la normale esecuzione del programma. Parallel Collectors: The new collectors in JDK are all designed to address the issue of garbage collection on multiprocessor systems. Because most garbage collection algorithms stop the world for some period of time, a single-threaded garbage collector can quickly become a scalability bottleneck, because all but one processor are idle while the garbage collector has suspended the user program threads. Two of the new collectors are designed to reduce collection pause time the parallel copying collector and the concurrent mark-sweep collector. The other, the parallel scavenge collector, is designed for higher throughput on large heaps La Java Virtual Machine ed il Compilatore HotSpot La Java HotSpot Virtual Machine costituisce l'implementazione Sun della specica della VM. Alcune delle caratteristiche più interessanti, come visto in [8, 9] dell'architettura sono: Frame interpretati, compilati e nativi sullo stesso Stack. Preemptive multithreading basato su Thread Nativi. Generational e Compacting Garbage Collection. 7

14 I compilatori JIT (Just-in-Time) sono essenzialmente tradizionali compilatori che traducono, il Bytecode Java in codice nativo per il processore host, al volo. Ovviamente bisogna tenere conto del fatto che, il compilatore JIT, girando a user-time, è soggetto ad un signicante delay che rallenta sicuramente la fare di startup dell'applicazione. Inoltre va considerato che la compilazione JIT potrebbe avere eetti abbastanza attenuati in Java, rispetto ad altri linguaggi come C/C++, a cause dei seguenti fattori: In Java tutti gli oggetti vengono allocati nello Heap ( diversamente da C++, dove alcuni oggetti giacciono nullo stack), da ciò deriva un tasso medio di allocazioni degli oggetti più alto, se comparato con quello in C++; va poi tenuto in considerazione che Java è un linguaggio Garbage Collected, quindi soggetto a diversi tipi di memory allocation overhead. In Java moltissimi metodi sono dichiarati virtual, ovvero, potenzialmente polimor. Le dicoltà che sono emerse, vengono risolte dall'architettura HotSpot mediante Adaptive Optimization, attraverso tre tecniche: HotSpot Detection: L'ottimizzazione adattativa risolve i problemi della JIT compilation avvantaggiandosi una interessante proprietà della maggior parte dei programmi. Virtualmente tutti i programmi passano la maggior parte del tempo di esecuzione eseguendo un piccola parte del codice. Il compilatore HotSpot analizza il codice, mentre lo esegue, per localizzare le aree critiche del programma; identicate queste aree critiche procede ad una ottimizzazione nativa delle stesse per migliorare le performance. Method Inlining: ha importanti beneci; riduce drammaticamente la frequenza delle invocazioni dei metodi. Ancora più importante, produce grossi blocchi di codice su cui è possibile eettuare ottimizzazione. 8

15 Dynamic Deoptimization: Il caricamento dinamico complica sensibilmente le procedure di inlining, poiché cambia le relazioni globali all'interno del programma (infatti il method inlining è un tecnica di analisi globale); una classe appena caricata infatti, potrebbe contenere dei metodi per cui è necessario l'inlining. La Java Hot Spot VM è capace di deottimizzare ed eventualmente ri-ottimizzare hot spots precedentemente ottimizzati. La Java Virtual Machine prevede due distinti modi di funzionamento: Client e Server; entrambi i modi di funzionamento sono simili, ma il modo server è ottimizzato per l'esecuzioni di applicazioni nel lungo periodo, applicazioni per le quali non è importante una fase di starup estremamente rapida, bensì una esecuzione del codice molto rapida. La Client VM, invece, è specializzata nel ridurre i tempi di startup e l'occupazione di memoria; queste caratteristiche la rendono particolarmente adatta a sistemi tipo client Java Threads In Java la gestione dei thread è eettuata associando i thread del sistema operativo host con ogni thread della VM in rapporto 1:1 Sia i metodi Java che quelli nativi condividono lo stesso stack, consentendo chiamate veloci tra applicazioni Java ed applicazioni C. I thread java sono fully preemptive, e supportati dal meccanismo di schedulazione del sistema operativo host. Uno dei vantaggi fondamentali dell'uso di thread nativi, e della loro schedulazione, è poter sfruttare le caratteristiche di multithreading, del sistema operativo, in modo trasparente Execution Engine La specica impone che ogni implementazione della specica, deve avere l'abilità di eseguire il bytecode Java (bc). La 9

16 Figura 1.2: Execution Engine tecnica più semplice che è possibile pensare, implementata nella prima JVM della SUN, è l'interpretazione del bytecode one a time; un'altra tecnica di esecuzione è la cosidetta JIT (Just-In-Time) Complilation. La tendenza, nell'ultimo periodo, è rivolta ad un approccio combinato, ibrido, detto Adaptive Optimization. Una Virtual Machine con ottimizzatore adattativo inizia ad eseguire una applicazione Java interpretando tutto il codice, ma monitorando l'esecuzione dello stesso. La maggior parte dei programmi passa il novanta percento del proprio tempo eseguendo circa il dieci percento del codice; monitorando l'esecuzione dell'applicazione, la virtual machine riesce a determinare quali sono gli Hot Spot. Nel momento in cui la VM stabilisce che un metodo è un Hot Spot avvia un thread incaricato di compilare il bytecode, di detto metodo, in nativo e di ottimizzarlo sfruttando alcune delle tecniche osservate in precedenza. Il fatto di selezionare dinamicamente il codice da compilare in nativo, costituisce in ogni caso una miglioria rispetto alla compilazione JIT tradizionale. 10

17 1.2.7 Error Handling Il momento ideale per catturare un errore è a tempo di compilazione; sfortunatamente non tutti gli errori possono essere riscontrati in questa fase. Con il termine Exception si intende Exceptional Event; una eccezione è un evento che si manifesta durante l'esecuzione di un programma alterando il normale usso d'esecuzione dello stesso. Quando si manifesta un errore in un metodo, la VM crea un oggetto d'eccezione e lo passa al sistema di runtime. Tale oggetto contiene informazioni circa l'errore, includendo il tipo e lo stato del programma. Nel momento in cui un metodo solleva una eccezione, il runtime system cerca di trovare qualcosa per gestirlo scorrendo la lista, ordinata, dei metodi che hanno portato il sistema nello stato di errore; questa lista è detta Call Stack. Il runtime system cerca, ricorsivamente, nel call stack, un metodo che contenga un blocco di codice che possa gestire l'eccezione. Questo blocco è detto Exception Handler. Quando viene identicato un handler opportuno, il runtime system passa l'eccezione all'handler. Se, dopo una ricerca esaustiva attraverso tutti i metodi sul call stack, non è possibile rintracciare un handler opportuno, viene invocato il Thread.dead, il programma termina e la VM va nello stato VMDeath 1. L'uso delle Eccezioni nella gestione degli errori è indubbiamente vantaggiosa, infatti permette di: Separare il codice di gestione degli errori dal regular code. Propagare gli errori in cima al call stack. Raggruppare e dierenziare i diversi tipi di errori. Una distinzione delle eccezioni presenta questa struttura: 1 Si veda in proposito la documentazione relativa a JVM TI: Java Virtual Machine Tool Interface, ove vengono descritti gli eventi principali atti a descrivere il comportamento e lo stato della JVM. 11

18 (a) (b) 1.3 Classicazione dei Fallimenti della Java Virtual Machine Checked Exception: sono condizioni eccezionali che un applicazione well-written dovrebbe anticipare e recuperare. Le Checked Exception sono soggette al vincolo del Catch/Specify; tutte le eccezioni sono checkd tranne quelle indicate da Error, RuntimeException e le loro sottoclassi. Errori: sono quelle condizioni eccezionali esterne all'applicazione, e che tipicamente l'applicazione non può né anticipare né recuperare. Runtime Exception: sono quelle condizioni eccezionali interne all'applicazione e che l'applicazione non può né anticipare né recuperare. Sono un sintono di un bug della programmazione, inteso come errore logico, oppure dovuto ad un errato uso delle API. Errors e Runtime Exceptions sono dette anche Unchecked Exception. L'unica sorgente di informazioni circa i Fallimenti, attualmente disponibile, è il Bug Database, disponibile su Le informazioni, in esso contenute, sono state fornite da utenti, nonostante questo, è possibile dimostrare che come costituisce un punto di inizio per 12

19 un'analisi dei fallimenti della JVM. Anzitutto è fondamentale stabilire dei criteri attraverso cui analizzare i dati, e quindi classicare i fallimenti sulla base di questi. Una possibilità è la seguente; distinguere, secondo [5], i fallimenti in: 13

20 Figura 1.3: Fault Classication 14

21 Failure Manifestation: VM Error Message: Eccezioni sollevate da un programma Java. OS Error Message: Errori del livello Sistema Operativo riportati all'utente, magari sotto forma di SIGNAL. Hang / Deadlock: Sono quegli scenari che non portano ad un crash della JVM, ma l'applicazione in esecuzione, oppure una sua parte, va in stallo. Silent Crash: La JVM entra nello stato VMDeath senza alcun report all'utente. Computation Error: I risultati ottenuti sono diversi da quelli attesi. Failure Source: Execution Unit OS Virtualizazion Layer Memory Management Unit (MMU) System Service Unit Severity: Un fallimento è denito catastroco se porta al crash della JVM. Un fallimento è detto non catastroco se la JVM continua nella sua esecuzione nonostante il fallimento. Environment: Sono quei fallimenti classicati in base alla correlazione della JVM con l'ambiente in cui essa è in esecuzione. VM Activity: E' la classicazione dei fallimenti correlata al workload cui è sottoposta la JVM. Failure Frequency: E' la classicazione stilata sulla base della frequenza con cui un certo fallimento occorre. 15

22 1.4 Conclusioni Come gia menzionato, la piattaforma Java ormai è presente in una moltitudine di contesti, alcuni dei quali particolarmente critici; E' stata anche ricordata la mancanza di supporto diretto alla Fault Tollerance; il connubio di questi due fattori, genera un problema grave e che urge arontare: Valutare il grado di robustezza e delle applicazioni Java. 16

23 Capitolo 2 Il Problema del Monitoraggio nel Contesto della Java Virtual Machine 2.1 Metodologie per lo Studio di Adabilità Applicazioni speciche per il monitoraggio di un paziente, per il controllo di processo, per l'online transaction processing, possiedono una forte connotazione di continuità di servizio; Ciò è ancora più vero se consideriamo che statisticamente i periodi di non funzionamento sono concentrati durante il picco di domanda. Queste applicazioni richiederebbero sistemi, virtualmente, infallibili, o ciò che è lo stesso, che parti del sistema possano fallire senza compromettere la disponibilità di fornire il servizio.risulta ovvio quindi, che negli ultimi decenni lo studio dell'adabilità dei sistemi informatici ha rivestito un ruolo primario sia nella comunità scientica che industriale. In particolare una analisi condotta da Jim Grey, e presentata in [4], dimostra come la percentuale più alta di fallimenti in un sistema sia dovuta al software e non al resto della piattaforma. La stessa analisi mostra lo stesso risultato 17

24 anche in termini di MTBF (Mean Time Between Failures ), in Figura 2.1 una sintesi dei risultati. Figura 2.1: Analisi dei Fallimenti del Tandem System Nel corso degli anni sono state sviluppate diverse metodologie per lo studio dei sistemi informatici esposti di seguito. 18

25 2.1.1 Measured-based Analysis Questa tecnica è in assoluto la più famosa tra i lavori connessi alla dependability analysis; l'idea è molto semplice: monitorare un sistema per ottenere dati circa i suoi fallimenti. Nella letteratura sono stati proposti molti modelli utili per modellare l'adabilità dei sistema sotto analisi partendo dai dati raccolti circa i fallimenti; in questi lavori è mostrato anche come, partendo dai suddetti dati, è possibile creare modelli sui fallimenti e sull'adabilità. Esempi di questa tecnica sono presenti in letteratura, come in [11]. Tuttavia questa tecnica non è particolarmente adatta allo studio dell'adabilità della Java Virtual Machine, non perchè il monitoraggio della JVM sia complesso, ma bensì, perchè i tempi di osservazione necessari a raccogliere un suciente numero di stati con livelli di workload ordinari sarebbero troppo elevati. Per poter utilmente sfruttare questa tecnica, dovrebbero essere pensati dei workloads specici, attività troppo complessa, soprattutto considerando che esistono numerose soluzioni diverse Dependability Benchmarking Il concetto di Dependability Benchmarking si allontana sostanzialmente da quello di Performance Benchmarking; in questi ultimi, diversi tipi di workloads sono imposti sul sistema da testare. Una apposita unità di monitoraggio fornirà i dati di misura estratti dagli esperimenti. Nei dependability benchmarks invece, al sistema vengono imposti sia un set di workloads che di faultloads vedi [7]. Ogni esperimento è costituito dall'imposizione di un workload, per simulare una condizione di funzionamento del sistema, e dall'iniezione di un fault estratto da un certo set di faultload. Tipicamente ogni dependability benchmark è costituito dai seguenti elementi vedi Figura 2.2: Benchmark Target : su cui vengono eettuate le misure Fault Injection Target : dove vengo iniettati i fault 19

26 Workload : per imporre una condizione di funzionamento Faultload : per portare il sistema in uno stato di cattivo funzionamento Monitor : per estrarre le misure dell'esperimento Analyzer : per fare analisi dei risultati ottenuti. Figura 2.2: Dependability Scenario I workloads, eseguiti sul sistema da testare, sono alterati con uno dei fault estratto dal set di faultloads. Le misure di adabilià, come la percentuale di fallimento, sono estratti dal target a mezzo dell'unità di monitoraggio. Un esempio molto rilevante di Dependability Benchmark è sicuramente DBench, un framework sviluppato per valutare l'adabilità di sistemi COTS e COTSbases. Il Dependability Benchmarking sembrerebbe essere interessante per studiare l'adabilità di una virtual machine; diversamente da altri sistemi software, l'adabilità di una macchina virtuale è compromessa sia dalle applicazioni che vengono eseguite su di essa, sia dal sistema operativo host come si evince dalla Figura 2.3. Risulta chiaro che esiste un nuovo scenario di analisi: ci saranno misure di robustezza sull'applicazione e di sensibilità del sistema operativo, ottenute attraverso: 1. Fault Injections nell'applicazione in esecuzione sulla virtual machine 20

27 Figura 2.3: Virtual Machine 2. Monitoraggio dei risultati Esperimenti mostrano che i sistemi di gestione delle eccezioni e di verica, built-in nella Java Virtual Machine, sono in grado di tollerare condizioni di funzionamento anomale dell'applicazione che è in esecuzione. L'analisi quindi, si deve spostare sul layer sottostante e alle interazioni tra la virtual machine e sistema operativo. Anche in questo caso risulta lampante l'importanza di possedere una unità di monitoraggio capace di mostrare questi dati, ed un modulo di analisi capace di interpretarli Error Injection Un approccio, teso ad accelerare il processo di fallimento, potrebbe essere iniettare errori al posto dei faults; questa tecnica però, richiede un esatto mapping tra i software faults ed gli errori. Deve essere assicurato che gli errori iniettati emulino esclusivamente i faults di origine software e non rispecchino fallimenti dell'hardware [6]. Le tecniche basate su Fault Emulation attraverso error injection garantiscono che l'errore iniettato sia rappresentativo di un fault. A causa della natura qualitativa delle fonti (essenzialmente i bug databases), è dicile denire un prolo di error injection coerente con l' Orthogonal Defect Classication (ODC); un ricerca approfondita nei bug da- 21

28 tabases non è stata suciente ad identicare sorgenti di fault che interessassero direttamente la Java Virtual Machine. Sarebbe necessario sviluppare una nuova classicazione ad hoc per il caso ; va notato però, che una analisi di questo tipo, risulterebbe applicabile esclusivamente a detto caso e dicilmente riapplicabile ad altri sistemi software Robustness Testing L'idea di Robustness Testing è stata proposta per la prima volta da Siewiorek e Koopman in [2]. L'idea di base è che un sistema software, supposto bug free, possa fallire. Questo approccio consiste nel fatto che è praticamente impossibile testare ogni singolo modulo di un sistema software, con ogni possibile dato di ingresso. Un esempio di Tool per il Robustness Testing è Ballista; sostanzialmente il testing avviene in quattro fasi: 1. Selezione del modulo da testare 2. Identicare l'iterfaccia (servizio) esposta da questo modulo 3. Forzare il modulo selezionato con dati di ingresso validi e non 4. Analizzare il comportamento del sistema, nel caso di Ballista, del sistema operativo. Il Robustness Testing sembra interessante nel contesto della analisi di adabilità ; Per eettuare questo tipo di test bisognerebbe: identicare le interfacce tra le applicazioni Java e la virtual machine (quindi il ByteCode Interpreter e la Native Interface). L'idea, sostanzialmente corretta, si scontra però con un problema di natura implementativa; la tecnica di collaudo esposta da Siewiorek non tiene conto dello stato interno del sistema da testare, è sostanzialmente un collaudo black-box, ciò rende la tecnica non adatta al contesto. Sulla base di questa considerazione è possibile fare almeno due osservazioni: 22

29 1. Bisogna Monitorare lo stato 2. E' necessario realizzare una forma di collaudo tipo white-box ; una buona soluzione potrebbe essere una mirata bytecode injection Aging Analysis Il termine Software Aging è stato introdotto da Kintala e Huang nel 1997 in []. Il fenomeno dell'invecchiamento si verica quando alcune risorse utilizzate da una applicazione sono soggette a depletion (utilizzate no in fondo): Esempi classici di questo fenomeno sono i memory leaks, buer overows, oating point errors. Un Aging Fault viene attivato diverse volte a causa dell'accumularsi degli errori, questo porta ad un fallimento del sistema. Gray in [4] espone una classicazione degli aging faults dove esistono: HeisenBugs: sono quei bugs che scompaiono durante la loro ricerca a causa anche di piccolissime perturbazioni introdotte dal bugcathcer BohrBugs: sono quei bugs che portano sempre il sistema in uno stato di cattivo funzionamento allorchè una certa operazione viene eettuata. Studi di invecchiamento su server SOAP-based sono stati proposti da Madeira in [3]; un altro caso di studio interessante circa l'aging in un webserver è proposto in [1]; in questo studio viene proposto un modello numerico attraverso cui predire il momento più adatto per bloccare il sistema, ed assicurasi quindi il ringiovanimento dello stesso. Nel corso del tempo diverse metodologie sono state messe a punto per identicare il fenomeno dell'aging e per prevdere il Time-To-Resuorce-Exhaustion. Nel caso specico della Java Virtual Machine è possibile arguire che i componenti interessati dal fenomeno dell'aging sono: il Runtime System, il Reference Handler ed il Compilatore JIT e nell'interfaccia con il sistema operativo. 23

30 2.2 Tecniche e Tecnologie per il Monitoraggio Le principali tecnologie disponibili per eettuare il monitoraggio di applicazioni Java, e della stessa Virtual Machine sono: JVM TI (Java Virtual Machine Tool Interface), JMX (Java Management Extensions) e le tecniche BCI (ByteCode Injection) Java Virtual Machine Tool Interface La JVM TM Tool Interface è una interfaccia di programmazione utilizzata dai tools di sviluppo e monitoraggio. Fornisce dei meccanismi per sondare lo stato e controllare l'esecuzione di applicazioni Java TM. JVM TI è una inferfaccia two-way; un client JVM TI, d'ora in avanti chiamato agent 1, può essere informato di interessanti occorrenze attraverso eventi. JVM TI può interrogare e controllare l'applicazione attraverso molteplici funzioni, alcune in risposta ad eventi ( e vengono dette callbacks ), altre indipendenti da questi. Gli agenti vengono eseguiti nello stesso processo e comunicano direttamente con la Virtual Machine che sta eseguendo l'applicazione da esaminare. La comunicazione avviene attraverso una interfaccia nativa. Tipicamente gli agenti sono abbastanza compatti, e possono essere controllati da un processo separato senza interferire con la normale esecuzione dell'applicazione target. Un tool di monitoraggio può essere scritto utilizzando direttamente JVM TI, oppure attraverso una interfaccia di alto livello. Gli agenti possono essere scritti in qualsiasi linguaggio nativo che supporti le convenzioni per le chiamate del linguaggio C e le denizioni C/C++. Le denizioni delle funzioni, tipi di dato, eventi e costanti sono contenute nell'header le jvmti.h; per utilizzarle è suciente aggiungere: 1 Di un agente JVM TI viene eettuato il Deploying nella forma di Shared Library:.so,.dylib... 24

31 #include <jvmti.h> al proprio codice. La libreria, ossia l'agente, deve esportare una funzione di start-up con il seguente prototipo che costituisce una sorta di entry-point per la libreria: JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM* vm, char* options, void* reserved) Questa funzione sarà invocata dalla VM al momento del caricamento della libreria. La VM dovrebbe caricare la libreria durante le primissime fasi dell'inizializzazione della VM, quando: le system properties vengano impostate l'intero set di capabilites è ancora raggiungibile 2 nessun bytecode è stato eseguito nessuna classe è stata caricata non è stato creato nessun oggetto Il valore di ritorno da Agent_onLoad è utilizzato per segnalare un errore. Ogni valore diverso da zero indica un errore e causa la terminazione della VM. La libreria potrebbe, opzionalmente, esportare una funzione di shutdown con il seguente prototipo: JNIEXPORT void JNICALL Agent_OnUnload(JavaVM* vm) Questa funzione verrà chiamata dalla VM quando la libreria sta per essere scaricata; è da notare la sostanziale dierenza tra la chiamata di questa funzione e l'occorrenza dell'evento VM_Death. Anchè l'evento VM_Death 2 le Capabilities, utilizzate per impostare la VM, sono disponibili solo in questa fase del ciclo di vita della VM. 25

32 venga inviato, la VM deve aver completato la propria inizializzazione, deve esistere un environment JVM TI valido che abbia impostato una callback per questo evento, e che l'evento sia stato abilitato. Queste fasi non sono necessarie invece per la funzione Agent_OnUnload e, tra l'altro, questa viene invocata anche se la libreria viene scaricata per altre ragioni. La Specica JVM TI supporta l'uso di più agenti simultaneamente. Ogni agente possiede il proprio environment; ciò implica che lo stato JVM TI è separato per ogni agente (i cambiamenti ad un ambiente non condizionano gli altri). Lo stato di un ambiente JVM TI comprende: Event Callbacks un set di eventi abilitati le Capabilities memory allocation / deallocation hooks Nonostante gli stati JVM TI siano separati, gli agenti ispezionano e modi- cano lo stato condiviso della VM, quindi anche l'ambiente nativo nel quale sono in esecuzione; ciò di ripercuote sul fatto che un agente potrebbe perturbare i risultati di altri agenti o portarli al fallimento. La specica quindi, delega al programmatore la responsabilità di evitare stati di funzionamento anomali dovuti all'interazione di più agenti. L'interfaccia JVM TI fornisce supporto diretto alla ByteCode Instrumentation, ossia all'abilità di alterare le istruzioni bytecode della Java Virtual Machine che formano il programma. Tipicamente queste alterazioni consistono nell'aggiunta di eventi al codice - body - di un metodo; ad esempio l'aggiunta, all'inizio del corpo di un metodo, di una chiamata a myagent.methodentered(). Fino a quando le modiche sono puramente additive, queste non modicano ne lo stato ne il comportamento dell'applicazione. Considerando che il codice aggiunto è standard bytecode, la VM 26

33 può eettuare su di esso, come sul resto del codice dell'applicazione, ogni ottimizzazione che ritenga opportuna. L'instrumentazione può essere iniettata in uno di questi tre modi: Static Instrumentation: Il class le è instrumentato prima di essere caricato nella VM; questa tecnica è fortemente sconsigliata. Load-Time Instrumentation: Quando un class le è caricato dalla VM, i raw bytes del class le sono inviati, per l'instrumentazione, all'agente. L'eveno ClassFileLoadHook fornisce questa funzionalità. Dynamic Instrumentation: Una classe gia caricata, è modicata. Questa funzionalità è fornita dalla funzione RedefineClasss. In Appendice viene presentato un semplice esempio di agente JVM TI (SimpleAgent.dylib) che illustra le funzionalità esposte Java Management extensions La Java Management Extensions (JXM) API è uno standard per la gestione ed il monitoraggio do applicazioni e servizi. Denisce una architettura di gestione, dei patterns di progettazione, delle APIs e dei servizi per progettare soluzioni web-based, distribuite, dinamiche e modulari, atte a gestiore risorse Java. La tecnologia JMX è nativa al linguaggio Java; ore estensioni di gestione ecienti e leggere a funzioni Java. Consiste di un set di speci- che e tools di sviluppo per gestire ambienti Java e progettare soluzioni di gestione e monitoraggio per applicazioni e servizi. Fornisce funzionalità di Instrumentazione del codice, un modo semplice e standard di scrivere smart agent, di integrazione con middleware e sistemi di monitoraggio preesistenti. Usi tipici della tecnologia JMX sono: Consultare e modicare la congurazione di una applicazione 27

34 Raccogliere statistiche circa il comportamento di una applicazione e rendere queste disponibili. Noticare cambiamenti di stato e condizioni di errore. 28

35 Figura 2.4: JMX Tiered Architecture La tecnologia JMX è denita da una architettura multi-tier dove le risorse gestite e le applicazioni di gestione sono integrate di un approccio plug and play come mostrato in Figura 2.4. Una certa risorsa è instrumentata attraverso uno o più oggetti Java conosciuti come Maneged Beans (MBeans), registrati in un oggetto server noto come MBean server. In dettaglio: Il livello instrumentazione contiene gli MBeans e le loro risorse da gestire. Fornisce una specica per implementare risorse gestibili attraverso JMX; una risorsa è manageble se è sviluppata in Java (oppure possiede un Java wrapper) ed è stata instrumentata in modo tale da poter essere gestita da un applicazione JMX-compilant. Una risorsa può essere instrumentata in due modi: staticamente e dinamicamente; gli Standard MBeans sono oggetti Java conformi ad un denito pattern di programmazione (ad esempio devono avere un costruttore e dei metodi setters e getters). Un Dynamic MBean è conforme ad una interfaccia specica che ore più essibilità a runtime. Le componenti chiave a livello instrumentazione sono gli MBeans, il modello di notica e le MBeans metadata classes. 29

36 Standard MBeans: il più semplice da progettare ed implementare. La loro interfaccia di gestione è denita dal nome dei metodi. Dynamic MBeans: Implementano una specica interfaccia ed espongono la loro interfaccia di gestione a runtime. Notication Model: JMX denisce un generico modello di notica basato sul modello degli eventi Java. MBeans Metadata Classes: Queste classi contengono le strutture per descrivere tute le complonenti di una interfaccia di gestione di un MBean: attributi, operazioni, notiche e costruttori. Il livello Agente contiene gli agenti JMX usati per esporre gli MBeans. Fornisce una specica per implementare gli agenti, i quali controllano le risorse e le rendono disponibili alla gestione da applicazioni remote. Gli agenti JMX sono costituiti da un MBean server e da un set di servizi per controllare gli MBeans. I JMX Managers accedono agli agenti MBeans tramite un protocol adapter (RMI, SNMP, HTTP...). Le componenti fondamentali di un agente sono l'mbean server ed i Services: MBean server: Un registro di oggetti che sono esposti alle operazioni di gestione in un agente. Agent Services: Oggetti che possono eettuare operazioni di gestione su di un MBean registrato sul server. I seguenti agenti sono disponibili in J2SE 5.0: Dynamic Class Loader: Attraverso un servizio m-let riceve ed instanzia nuove classi e librerie native da arbitrarie locazioni remote. Monitors: Osserva il valore di un attributo degli MBeans e può noticare altri oggetti di cambiamenti di stato. 30

37 Timers: Forniscono un meccanismo di scheduazione. Relation Service: Denisce le associazioni tra MBeans e forza la cardinalità della relazione basandosi su tipi predeniti di relazioni. Il livello Manager contiene le componenti che abilitano le applicazioni di gestione a comunicare con gli agenti JMX. Fornisce le interfaccie per implementare JMX Managers. In Appendice viene presentato un semplice esempio di agente JMX che illustra le funzionalità esposte Bytecode Injection La Bytecode Transformation è una potente tecnica per estendere od adattare, dinamicamente, software Java utilizzando dei tranformers che automaticamente riscrive classi compilate. i Bytecode Transformers sono utilizzati per: Integrare componenti software sviluppati separatamente Instrumentare applicazioni a scopo di monitoraggio, debugging o pro- ling Estendere applicazioni con nuove funzionalità di sicurezza, controllo ed altro I transformers modicano software esistente attraverso un parsing automatico e la manipolazione di classi compilate rappresentate da classle. Le nuove funzionalità, che si vuole aggiungere al software, sono completamente disaccoppiate dall'applicazione target ed implementate direttamente nel trasformatore. Considerando che i Bytecode Transformers agiscono sui programmi compilati, sono in grado di consentire le cosiddette late adaptations / extensions nonstante il codice sorgente non sia disponibile. Esperimenti 31

38 mostrano le enormi potenzialità delle tecniche di bytecode injection anche, e soprattutto in sistemi software network-oriented. Nonostante il successo delle ricerche, ci sono alcuni aspetti critici che ostacolano l'accettazione delle tecniche BCI come strumento di sviluppo: La costruzione dei trasformatori richiede: una conoscenza estremamente approfondite della struttura della Java Classle Rappresentation e del ByteCode Instruction Set, la stesura di un insieme di regole che disciplinino la scrittura di detti trasformatori in modo che l'inserimento del bytecode sia sicura. Sorge il problema adesso, di stabilire quando eettuare l'inserimento del codice; per questo scopo sono state individuate tre casi: 1. Staticamente: i classle vengono modicati attraverso BCI prima di essere caricati nella Java Virtual Machine dal ClassLoader. 2. Load Time: con questo approccio i classle vengono modicati prima che la Java Virtual Machine possa accedere alla classe; una buona soluzione per implementare questa strategia è progettare un apposito ClassLoader che integri un trasformatore, ciò garantisce la correttezza del classle caricato nella virtual machine; questa strategia infatti, ha il vantaggio di servirsi, automaticamente, del meccanismo di verica del Classloader vedi Figura 2.5. Figura 2.5: Trasformazione di classi a Load Time 32

39 3. Full Dynamic: con questo approccio è possibile modicare una classe potenzialmente gia eseguita dalla Java Virtual Machine, attraverso la tecnica dell'hotswapping; modiche puramente additive, non creano nessuna alterazione nel comportamento e di tutto il software in esecuzione su di essa. La letteratura propone moltissime librerie per la bytecode injection, le più utilizzate sono sicuramente: BCEL (ByteCode Engeneering Library) e Javassist. Nel panorama delle librerie per BCI, tardano ad aacciarsi soluzioni di basso livello sulla falsa riga di java_crw_demo. 33

40 2.3 Tools di Monitoraggio Esistono, nel panorama del software commerciale e non, delle soluzioni per il monitoraggio ; nel corso della prossima sezione esamineremo due utilities: JProler e HPROF. Lo scopo è mostrare come questi tools non siano adatti ad un monitoraggio orientato alla raccolta di dati per scopi di Dependability Analysis ej-technologies, JProler JProler è un software commerciale orientato in modo particolare alla analisi delle performance di una applicazione in esecuzione sulla Java Virtual Machine. Si basa sostanzialmente su JVMPI (Java Virtual Machine Proling Interface) e JVMTI (Java Virtual Machine Tool Interface); questa scelta è stata eettuata per garantire compatibilità con le virtual machine 1.4.x. L'instrumentazione completa non è possibile sulle virtual machine 1.5.x, dove l'interfacca di proling è divenuta deprecated; In Figura 2.6 alcuni esempi d'uso di JProler: 34

41 Un'Architettura per il monitoraggio online (a) Pro ling Settings (b) Memory Usage Figura 2.6: Esempi di funzionamento di JPro ler Sun Microsystems, HPROF: Heap Pro ler Heap Pro ler è essenzialmene una piccola demo fornita con i sorgenti allo scopo di dimostrare l'utilizzo dell'interfaccia JVMTI e le possibilità di instrumentazione fornite da java_crw_demo; tipicamente il suo uso è correlato a quello di un tool di visualizzazione dell'heap dump (Hat). 35

Realizzazione di un applicazione per la visualizzazione grafica didattica e di debug per algoritmi in Java

Realizzazione di un applicazione per la visualizzazione grafica didattica e di debug per algoritmi in Java La Sapienza Università di Roma Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Anno Accedemico 2008-2009 Relazione finale su progetto interno Realizzazione di un applicazione per la visualizzazione

Dettagli

Realizzazione di un framework di monitoring per l'analisi di sistemi critici Anno Accademico 2013/2014

Realizzazione di un framework di monitoring per l'analisi di sistemi critici Anno Accademico 2013/2014 tesi di laurea specialistica Realizzazione di un framework di monitoring per l'analisi di sistemi critici Anno Accademico 2013/2014 relatore Ch.mo Prof. Domenico Cotroneo correlatore Ch.mo ing. Antonio

Dettagli

Class File bytecode. Class loader. Verifier JIT. Run-time System

Class File bytecode. Class loader. Verifier JIT. Run-time System Un file.class è ottenuto compilando il codice sorgente Java. Esso contiene il bytecode, ovvero la sequenza di istruzioni per la JVM, ed anche molte informazioni simboliche. Il bytecode è il linguaggio

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

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

Intrusion Detection System

Intrusion Detection System Capitolo 12 Intrusion Detection System I meccanismi per la gestione degli attacchi si dividono fra: meccanismi di prevenzione; meccanismi di rilevazione; meccanismi di tolleranza (recovery). In questo

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Sistema informativo per la gestione dei processi

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

Introduzione alla Virtualizzazione

Introduzione alla Virtualizzazione Introduzione alla Virtualizzazione Dott. Luca Tasquier E-mail: luca.tasquier@unina2.it Virtualizzazione - 1 La virtualizzazione è una tecnologia software che sta cambiando il metodo d utilizzo delle risorse

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

Un approccio innovativo alla tecnica di robustness testing del sistema operativo Linux

Un approccio innovativo alla tecnica di robustness testing del sistema operativo Linux tesi di laurea Un approccio innovativo alla tecnica di robustness testing del sistema Anno Accademico 2009/2010 relatore Ch.mo prof. Domenico Cotroneo correlatori Ing. Domenico Di Leo Ing. Roberto Natella

Dettagli

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

Piattaforma aziendale IBM Cognos per Business Intelligence

Piattaforma aziendale IBM Cognos per Business Intelligence Piattaforma aziendale IBM Cognos per Business Intelligence Considerazioni principali Ottimizzate le prestazioni con l'elaborazione in-memory e l'evoluzione dell'architettura Ottimizzate i vantaggi dell'implementazione

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

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi Linguaggio Java Robusto Non permette costrutti pericolosi Eredità Multipla Gestione della Memoria Orientato agli oggetti Ogni cosa ha un tipo Ogni tipo è un oggetto (quasi) Protegge e gestisce dagli errori

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

Quando si sa chiaramente come si deve comportare l applicazione si può analizzare una possibile soluzione applicativa.

Quando si sa chiaramente come si deve comportare l applicazione si può analizzare una possibile soluzione applicativa. Introduzione alla tecnologia JMX 1 Viene analizzata l architettura sottostante le Java Managment Extensions (JMX) mostrandone un utilizzo applicativo e analizzando altri possibili scenari d uso di Ivan

Dettagli

Componenti di Sistemi Operativi. System Call Programmi di sistema Componenti di un SO Servizi di SO

Componenti di Sistemi Operativi. System Call Programmi di sistema Componenti di un SO Servizi di SO Componenti di so 1 Componenti di Sistemi Operativi System Call Programmi di sistema Componenti di un SO Servizi di SO 2 System Call Le system call forniscono l'interfaccia tra running program e SO Generalmente

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Sistemi Web Tolleranti ai Guasti

Sistemi Web Tolleranti ai Guasti Sistemi Web Tolleranti ai Guasti Candidato: Paolo Romano Relatore: Prof. Salvatore Tucci Correlatore: Prof. Bruno Ciciani Sommario Il problema: garantire semantica exactly once alle transazioni Web. Sistema

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Servers Activatable. Massimo Merro Programmazione di Rete 166 / 193

Servers Activatable. Massimo Merro Programmazione di Rete 166 / 193 Servers Activatable Nelle lezioni precedenti abbiamo detto che una referenza remota ad un server di tipo UnicastRemoteObject rimane valida finchè il server è in esecuzione. Quando il server termina, o

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

RMI: metodi equals e hashcode

RMI: metodi equals e hashcode RMI: metodi equals e hashcode Per verificare se due oggetti remoti contengono gli stessi dati, la chiamata indirizzata al metodo equals() avrebbe bisogno di contattare i server dove si trovano gli oggetti

Dettagli

Le operazioni di allocazione e deallocazione sono a carico del sistema.

Le operazioni di allocazione e deallocazione sono a carico del sistema. Allocazione della memoria In C++ è possibile creare (allocare) variabili in maniera statica o dinamica. Nell allocazione statica una variabile esiste ed è utilizzabile dal momento della sua dichiarazione

Dettagli

La genealogia di Windows. Windows NT e Windows 95/98. Dimensioni del codice. Parte IX. Windows

La genealogia di Windows. Windows NT e Windows 95/98. Dimensioni del codice. Parte IX. Windows La genealogia di Windows Parte IX Windows Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 DOS: sistema operativo monoutente Windows 3.1 interfaccia a finestre che gira su DOS Windows 95/98

Dettagli

Parte IX. Windows. Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1

Parte IX. Windows. Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 Parte IX Windows Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 La genealogia di Windows DOS: sistema operativo monoutente Windows 3.1 interfaccia a finestre che gira su DOS Windows 95/98

Dettagli

Realizzazione di un tool di instrumentazione automatica a supporto della failure analysis

Realizzazione di un tool di instrumentazione automatica a supporto della failure analysis tesi di laurea Realizzazione di un tool di instrumentazione automatica a supporto della failure analysis Anno Accademico 2011/2012 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Antonio Pecchia

Dettagli

Tesi di Laurea Automazione del testing delle Interfacce utente di applicazioni WEB:

Tesi di Laurea Automazione del testing delle Interfacce utente di applicazioni WEB: Tesi di Laurea Automazione del testing delle Interfacce utente di applicazioni WEB: un caso di studio Anno accademico 2009 / 2010 Relatore Ch.mo prof. Porfirio Tramontana Correlatore Ch.mo Ing. Domenico

Dettagli

Programmazione ad Oggetti. Java Parte I

Programmazione ad Oggetti. Java Parte I Programmazione ad Oggetti Java Parte I Overview Caratteristiche generali 1 Caratteristiche generali Un moderno linguaggio orientato agli oggetti Pensato per lo sviluppo di applicazioni che devono essere

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

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

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

Nascita di Java. Che cos e Java? Caratteristiche di Java. Java: linguaggio a oggetti

Nascita di Java. Che cos e Java? Caratteristiche di Java. Java: linguaggio a oggetti Nascita di Java L uscita di Java, verso la metà degli anni novanta, fu accolta con molto entusiasmo dalla comunità dei programmatori e dei provider di servizi internet perché permetteva agli utenti del

Dettagli

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

19. Introduzione al multi-threading

19. Introduzione al multi-threading 19. Introduzione al multi-threading Marco Faella Dip. Ing. Elettrica e Tecnologie dell'informazione Università di Napoli Federico II Corso di Linguaggi di Programmazione II I thread I thread, o processi

Dettagli

JAVA REAL-TIME: ANALISI DELL ARCHITETTURA E VALUTAZIONE SPERIMENTALE DELLA PIATTAFORMA SOLARIS 10.9

JAVA REAL-TIME: ANALISI DELL ARCHITETTURA E VALUTAZIONE SPERIMENTALE DELLA PIATTAFORMA SOLARIS 10.9 JAVA REAL-TIME: ANALISI DELL ARCHITETTURA E VALUTAZIONE SPERIMENTALE DELLA PIATTAFORMA SOLARIS 10.9 Candidato: Marco Nanni RELATORE: Chiar.mo Prof. Eugenio Faldella CORRELATORI Chiar.mo Prof. Marco Prandini

Dettagli

INDICE. Indice. Introduzione

INDICE. Indice. Introduzione V Indice Introduzione XIII Capitolo 1 La programmazione multithread 1 1.1 Cosa sono i thread 2 Utilizzare i thread per dare una possibilità ad altri task 9 Avvio ed esecuzione dei thread 10 Esecuzione

Dettagli

Processi e thread. Dipartimento di Informatica Università di Verona, Italy. Sommario

Processi e thread. Dipartimento di Informatica Università di Verona, Italy. Sommario Processi e thread Dipartimento di Informatica Università di Verona, Italy Sommario Concetto di processo Stati di un processo Operazioni e relazioni tra processi Concetto di thread Gestione dei processi

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

Fondamenti di Informatica T-1 CdS Ingegneria Informatica a.a. 2011/2012. Introduzione a Visual Studio 2005/2008/2010

Fondamenti di Informatica T-1 CdS Ingegneria Informatica a.a. 2011/2012. Introduzione a Visual Studio 2005/2008/2010 Fondamenti di Informatica T-1 CdS Ingegneria Informatica a.a. 2011/2012 Introduzione a Visual Studio 2005/2008/2010 1 Outline Solution e Project Visual Studio e linguaggio C Visual Studio schermata principale

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Il sistema operativo TinyOS

Il sistema operativo TinyOS tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Domenico Cotroneo candidato Giovanni Chierchia Matr. 534 / 804 ::. Obiettivi del lavoro di tesi Studio del sistema operativo TinyOS Studio

Dettagli

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

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

Programmazione in Java Parte I: Fondamenti

Programmazione in Java Parte I: Fondamenti Programmazione in Java Parte I: Fondamenti Lezione 1 Dott. Marco Faella Riferimenti Testi consigliati: Progettazione del software e design pattern in Java di C.S. Horstmann Apogeo Gli esempi di codice

Dettagli

Java? Sì, grazie. Scopo del corso

Java? Sì, grazie. Scopo del corso Modulo di Java? Sì, grazie Il linguaggio di Internet? Portabilità su qualunque piattaforma (non solo calcolatori): It works everywhere Supporto e disponibilità di strumenti, librerie e documentazione garantiti

Dettagli

Uno strumento per il deployment automatico di performance test su piattaforme per la distribuzione di dati

Uno strumento per il deployment automatico di performance test su piattaforme per la distribuzione di dati tesi di laurea Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Controneo correlatore Ing. Christiancarmine Esposito candidato Antonella Niola Matr. 534/158 .:: Contesto ::. www.cosmiclab.it Il

Dettagli

Analisi della dependability di un middleware per la

Analisi della dependability di un middleware per la tesi di laurea Analisi della dependability di un middleware per la distribuzione ib i dei dati conforme allo standard d OMG Anno Accademico 2005-2006 relatori Ch.mo prof. Stefano Russo Ch.mo prof. Domenico

Dettagli

LINGUAGGI DI PROGRAMMAZIONE LINGUAGGI DI BASSO LIVELLO

LINGUAGGI DI PROGRAMMAZIONE LINGUAGGI DI BASSO LIVELLO LINGUAGGI DI PROGRAMMAZIONE LINGUAGGI DI BASSO LIVELLO Linguaggio macchina Uno per ogni processore o famiglia di processori Linguaggio assembler Versione simbolica di quello macchina. LINGUAGGI DI ALTO

Dettagli

Programmazione ad oggetti

Programmazione ad oggetti DAIS Univ. Ca' Foscari Venezia Programmazione ad oggetti Samuel Rota Bulò Informazioni generali Docente: Samuel Rota Bulò @email: srotabul@dais.unive.it Homepage: http://www.dais.unive.it/~srotabul/ ooprogramming2012.html

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Funzioni e strategie di progettazione: dai kernel monolitici

Dettagli

Capitolo 5: I thread

Capitolo 5: I thread Capitolo 5: I thread Generalità. Modelli multithread. Problematiche relative ai thread. Pthread. 5.1 I thread Il thread è un flusso di controllo relativo ad un dato processo. Molti sistemi operativi moderni

Dettagli

Metodologie di ottimizzazione e analisi prestazionale degli elaboratori

Metodologie di ottimizzazione e analisi prestazionale degli elaboratori Metodologie di ottimizzazione e analisi prestazionale degli elaboratori Seminario del corso di Architettura degli elaboratori elettronici LABORATORIO UNIVERSITA CATTOLICA DI BRESCIA 23 novembre 2005 Roberto

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

Virtualizzazione e Macchine Virtuali

Virtualizzazione e Macchine Virtuali Virtualizzazione e Macchine Virtuali Gabriele D Angelo, Ludovico Gardenghi {gda, garden}@cs.unibo.it http://www.cs.unibo.it/~gdangelo/ http://www.cs.unibo.it/~gardengl/ Università di Bologna Corso di Laurea

Dettagli

Lezione 10. Scheduling nei sistemi multiprocessori. Esempio: P=2 processori. Scheduling dei processi

Lezione 10. Scheduling nei sistemi multiprocessori. Esempio: P=2 processori. Scheduling dei processi Lezione 10 Cenni ai sistemi operativi distribuiti 2. Gestione della CPU e della memoria nei multiprocessori Gestione dei processi Scheduling Bilanciamento del carico Migrazione dei processi Gestione della

Dettagli

Strategie per il miglioramento dei log applicativi basate su Software Fault Injection

Strategie per il miglioramento dei log applicativi basate su Software Fault Injection tesi di laurea Anno Accademico 2010/2011 relatore Ch.mo prof. Marcello Cinque correlatore Ing. Roberto Natella candidato Daniele Esposito Matr. 534/003280 Introduzione Software Fault: difetti presenti

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

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

Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010

Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010 Soft Control facile con RTX e Windows Embedded Standard 7 RTX 2009: funzionalità ed uso pratico Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010 Definizione di Sistema Tempo Reale: Definizione

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi a.a. 2010/2011 Francesco Fontanella Il Sistema Operativo Sistema Operativo 2 Il Sistema Operativo Il Sistema Operativo è uno strato

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

Realizzazione di uno strumento web-based per la simulazione remota di reti di sensori senza filo

Realizzazione di uno strumento web-based per la simulazione remota di reti di sensori senza filo tesi di laurea Realizzazione di uno strumento web-based per la simulazione remota di reti di sensori senza filo Anno Accademico 2009/2010 relatore Ch.mo prof. Marcello Cinque correlatore Ing. Catello di

Dettagli

Introduzione alla Progettazione per Componenti

Introduzione alla Progettazione per Componenti Introduzione alla Progettazione per Componenti Alessandro Martinelli 6 ottobre 2014 Obiettivo del Corso Il Progetto Software Reale Il Componente Software La Programmazione Ad Oggetti Fondamenti di Informatica

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software.

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Test Giulio Destri Ing. del Software: Test - 1 Scopo del modulo Definire

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

Un sistema per l'emulazione delle reti su cluster di macchine virtuali Anno Accademico 2007/2008

Un sistema per l'emulazione delle reti su cluster di macchine virtuali Anno Accademico 2007/2008 tesi di laurea Un sistema per l'emulazione delle reti su cluster di macchine virtuali Anno Accademico 2007/2008 relatore Ch.mo prof. Roberto Canonico correlatore ing. Pasquale Di Gennaro candidato Roberto

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

Realizzazione di un Tool per l iniezione automatica di difetti all interno di codice Javascript

Realizzazione di un Tool per l iniezione automatica di difetti all interno di codice Javascript tesi di laurea di difetti all interno di codice Javascript Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo ing. Domenico Amalfitano candidato Vincenzo Riccio Matr.

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Analisi empirica dei meccanismi di log in sistemi open-source!

Analisi empirica dei meccanismi di log in sistemi open-source! tesi di laurea! Analisi empirica dei meccanismi di log in sistemi open-source! Anno Accademico 2010/2011! relatore! Ch.mo prof. Domenico Cotroneo! Correlatore! Ing. Antonio Pecchia! Candidato! Assunta

Dettagli

Realizzazione di un sistema di logging prototipale per la piattaforma

Realizzazione di un sistema di logging prototipale per la piattaforma tesi di laurea Realizzazione di un sistema di logging prototipale per la piattaforma Android Anno Accademico 2011 / 2012 relatore Ch.mo prof. Marcello Cinque candidato Dario De Meis Matr. 528 / 741 Smartphone

Dettagli

Programmazione Java Avanzata Spring - JDBC

Programmazione Java Avanzata Spring - JDBC Programmazione Java Avanzata Spring - JDBC Ing. Gianluca Caminiti Riferimenti Spring http://www.springsource.org/ (scaricate il reference) Beginning Spring 2 - From Novice to Professional. APress. 2008

Dettagli

Una metodologia per la definizione dei livelli di criticità dei componenti di un sistema software complesso

Una metodologia per la definizione dei livelli di criticità dei componenti di un sistema software complesso tesi di laurea Anno Accademico 2006/2007 relatore Ch.mo Prof. Massimo Ficco correlatore Ing. Roberto Pietrantuono candidato Antonio Pecchia Matr. 885/108 Sistemi safety-critical Sistemi complessi i cui

Dettagli

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico Impossibile visualizzare l'immagine. Struttura di un sistema operativo Struttura dei Sistemi Operativi Servizi di un sistema operativo Interfaccia Utente Capitolo 2 -- Silberschatz Chiamate di sistema

Dettagli

Supporto al Sistema Operativo

Supporto al Sistema Operativo Supporto al Sistema Operativo Middleware di supporto al sistema operativo in sistemi distribuiti Funzione del nucleo Modelli architetturali di SO Decomposizione delle funzionalità Processi, thread, processi

Dettagli

Uno strumento per l emulazione di fallimenti hardware in sistemi virtualizzati

Uno strumento per l emulazione di fallimenti hardware in sistemi virtualizzati Tesi di laurea magistrale Uno strumento per l emulazione di fallimenti hardware in sistemi virtualizzati Anno Accademico 2012/2013 relatore Ch.mo prof. Marcello Cinque Ing. Antonio Pecchia correlatore

Dettagli

La prossima ondata di innovazione aziendale introdotta da Open Network Environment

La prossima ondata di innovazione aziendale introdotta da Open Network Environment Panoramica della soluzione La prossima ondata di innovazione aziendale introdotta da Open Network Environment Panoramica La crescente importanza dei ruoli assunti da tecnologie come cloud, mobilità, social

Dettagli

Java. Traditional portability (ideal)

Java. Traditional portability (ideal) 1 Java JAVA: una introduzione 2 Traditional portability (ideal) C-code (Linux) (Pentium) Executable (Linux) Executable (Win32) Linux Windows 32 (Mac) Executable (Mac) Mac 1 1 3 Portability of Java programs

Dettagli

Processi in Linux. Igino Corona igino.corona@diee.unica.it. 20 Ottobre 2009

Processi in Linux. Igino Corona igino.corona@diee.unica.it. 20 Ottobre 2009 Sistemi Operativi Processi in Linux Igino Corona igino.corona@diee.unica.it 20 Ottobre 2009 Contenuti della lezione Come funzionano i programmi in Linux? Schema base di esecuzione di un programma Modalità

Dettagli

Java Virtual Machine

Java Virtual Machine Java Virtual Machine programmi sorgente: files.java compilatore files.class bytecode linker/loader bytecode bytecode Java API files.class interprete macchina ospite Indipendenza di java dalla macchina

Dettagli

Ingegneria del Software - Il Ciclo Lungo

Ingegneria del Software - Il Ciclo Lungo Ingegneria del Software - Il Ciclo Lungo Alessandro Martinelli alessandro.martinelli@unipv.it 10 Marzo 2014 Il Ciclo Lungo Il Versioning e la Condivisione di Codice Organizzazione dei Pacchetti La Modellazione

Dettagli

Programmazione Java Avanzata Concetti su Java

Programmazione Java Avanzata Concetti su Java Programmazione Java Avanzata Concetti su Java Ing. Giuseppe D'Aquì Testi di Riferimento Java ( R. Liguori, P. Liguori), O'Reilly Hops Tecniche Nuove (2008) Java Virtual Machine Il codice scritto in Java

Dettagli

Analisi e sviluppo di un sistema automatico per la segnalazione di stati anomali dei job del Data Center S.Co.P.E.

Analisi e sviluppo di un sistema automatico per la segnalazione di stati anomali dei job del Data Center S.Co.P.E. Tesi di Laurea Analisi e sviluppo di un sistema automatico per la segnalazione di stati anomali dei job del Data Center S.Co.P.E. Anno Accademico 2011/2012 Relatore Ch.mo prof. Marcello Cinque Correlatore

Dettagli

Enterprise @pplication Integration Software S.r.l.

Enterprise @pplication Integration Software S.r.l. SAP rel.1.0 : SAP State: Final Date: 03-27-200 Enterprise @pplication Integration Software S.r.l. Sede legale: Via Cola di Rienzo 212-00192 Rome - Italy Tel. +39.06.6864226 Sede operativa: viale Regina

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

Progettazione di interfacce web indipendenti dal dispositivo

Progettazione di interfacce web indipendenti dal dispositivo Progettazione di interfacce web indipendenti dal dispositivo Candidato Izzo Giovanni, Matr. 41/1305 Relatore Prof. Porfirio Tramontana 1 Panoramica su contesto ed obiettivi Il contesto della tesi è legato

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

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI 1 Web Link Monitor... 2 2 Database Browser... 4 3 Network Monitor... 5 4 Ghost Site... 7 5 Copy Search... 9 6 Remote Audio Video

Dettagli

Informatica 3. Informatica 3. LEZIONE 6: Il controllo dell esecuzione. Lezione 6 - Modulo 1. Errori durante l esecuzione. Il controllo dell esecuzione

Informatica 3. Informatica 3. LEZIONE 6: Il controllo dell esecuzione. Lezione 6 - Modulo 1. Errori durante l esecuzione. Il controllo dell esecuzione Informatica 3 Informatica 3 LEZIONE 6: Il controllo dell esecuzione Modulo 1: La gestione delle eccezioni Modulo 2: Programmazione concorrente Lezione 6 - Modulo 1 La gestione delle eccezioni Politecnico

Dettagli

APPENDICE A Servlet e Java Server Page

APPENDICE A Servlet e Java Server Page APPENDICE A Servlet e Java Server Page A.1 Cosa è una Servlet e come funziona Una servlet è un particolare tipo di applicazione Java, in grado di essere eseguita all'interno di un web server e di estenderne

Dettagli

Fondamenti di Informatica: Sistemi Operativi 1. Introduzione

Fondamenti di Informatica: Sistemi Operativi 1. Introduzione Introduzione Fondamenti di Informatica: Sistemi Operativi 1 Elaboratori necessitano di SOFTWARE SOFTWARE DI SISTEMA (SISTEMI OPERATIVI): fanno funzionare le varie componenti del computer e permettono all

Dettagli

Allegato 2: Prospetto informativo generale

Allegato 2: Prospetto informativo generale Gara a procedura ristretta accelerata per l affidamento, mediante l utilizzo dell Accordo Quadro di cui all art. 59 del D.Lgs. n. 163/2006, di Servizi di Supporto in ambito ICT a InnovaPuglia S.p.A. Allegato

Dettagli

Il Paradigma REST per lo sviluppo di applicazioni Web 2.0

Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 tesi di laurea Anno Accademico 2006/2007 Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Marcello Cinque candidato Antonio Alonzi Matr.

Dettagli

Cosa è un Sistema Operativo (S.O.)

Cosa è un Sistema Operativo (S.O.) Cosa è un Sistema Operativo (S.O.) Modulo software costituito da un insieme di programmi per: permettere all utente l uso dell elaboratore senza la conoscenza approfondita dell hardware S.O. supporto all

Dettagli

SISTEMI OPERATIVI 3 febbraio 2014 corso A nuovo ordinamento e parte di teoria del vecchio ordinamento indirizzo SR

SISTEMI OPERATIVI 3 febbraio 2014 corso A nuovo ordinamento e parte di teoria del vecchio ordinamento indirizzo SR SISTEMI OPERATIVI 3 febbraio 2014 corso A nuovo ordinamento e parte di teoria del vecchio ordinamento indirizzo SR Cognome: Nome: Matricola: 1. Ricordate che non potete usare calcolatrici o materiale didattico,

Dettagli