Auto-Ottimizzazione Basata su Simulazione in Sistemi di Tipo Autonomic

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Auto-Ottimizzazione Basata su Simulazione in Sistemi di Tipo Autonomic"

Transcript

1 Università degli Studi del Sannio Dottorato di Ricerca in Ingegneria dell Informazione Auto-Ottimizzazione Basata su Simulazione in Sistemi di Tipo Autonomic Relatore: Prof. Umberto Villano Coordinatore: Prof. Michele Di Santo Candidato: Emilio Pasquale Mancini 2006

2 Indice 1 I sistemi di tipo autonomic L architettura di riferimento Livelli di maturità La descrizione dei sistemi e la simulazione MetaPL Estensioni per i Web Services Esempio Estensioni per i sistemi di tipo autonomic HeSSE L uso del simulatore HeSSE Interfacce Web Service per i tools HeSSEws MetaPLws L auto-ottimizzazione MAWeS L architettura di MAWeS La gestione delle simulazioni: il package core La gestione dei servizi di secondo livello: Il package services La gestione dei filtri: il package metafilter MAWeSclient Ciclo di esecuzione Sviluppo di Web Services di tipo autonomic Sistemi ad agenti mobili

3 Indice 2 4 Risultati sperimentali Applicazioni orientate ai servizi Valutazione delle prestazioni del framework Applicazioni soft-realtime Servizi composti Servizi composti e riconfigurazione su invocazione Servizi composti e riconfigurazione reattiva Ricerche correlate Conclusioni A Core ed estensioni di MetaPL A.1 MetaPL Core A.2 Estensione per OpenMP A.3 Estensione per MPI A.4 Estensione Object Oriented B Integrazione in Eclipse: Perforce B.1 HeSSEgraphs Indice analitico Riferimenti bibliografici

4 Introduzione I sistemi distribuiti sono intrinsecamente complessi, sia dal punto di vista dell analisi, sia da quello dell implementazione che della manutenzione. La loro importanza nel panorama informatico è cresciuta sempre più negli ultimi anni, ricevendo un impulso dalla diffusione delle reti di comunicazione e dall esigenza di avere sistemi sempre più performanti che, allo stesso tempo, non presentassero costi proibitivi. Con lo sviluppo delle tecnologie di comunicazione, dalle socket alle librerie a scambio di messaggi, da CORBA ai Web Services, costruire questi sistemi è diventato più semplice da un punto di vista tecnico. Purtroppo accanto a questa semplicità, si è avuto un forte incremento della complessità architetturale. I sistemi particolarmente complessi si sono rivelati, naturalmente, anche difficilmente gestibili, piuttosto vulnerabili e, in alcuni casi, quasi impossibili da ottimizzare. Nell ambito della ricerca sui sistemi informatici distribuiti, è stato quindi aperto un filone teso a rendere i sistemi autonomi, in grado, cioè, di gestire autonomamente i parametri che riguardano la propria configurazione (sistemi self-configuring), i propri errori (sistemi self-healing), la propria sicurezza (sistemi self-protecting), la propria ottimizzazione (sistemi self-optimizing). L obiettivo di questa tesi è lo studio dei sistemi autonomi autoottimizzanti e il conseguente sviluppo di un framework, chiamato MAWeS, con il quale poter implementare applicazioni autonome auto-ottimizzanti. Inizialmente sarà presentata una panoramica introduttiva sui sistemi autonomi (autonomic), quindi verranno descritti gli strumenti e

5 Indice 4 le tecnologie usate nello sviluppo del framework. Saranno, quindi, descritte in dettaglio la progettazione e l implementazione del framework MAWeS, facendo un particolare riferimento alle architetture orientate alla cooperazione dei servizi (SOA). Ed infine, nell ultima parte, saranno mostrati i casi di studio usati per la validazione del sistema e ne saranno discussi i risultati, prima di delineare gli sviluppi futuri del presente lavoro.

6 1 I sistemi di tipo autonomic Nell uso dei sistemi informatici di dimensioni medio-grandi ci si scontra con una difficoltà sempre maggiore per la gestione e la configurazione man mano che crescono le esigenze degli utenti e ci si rivolge a nuove tecnologie. In particolare l integrazione di strumenti diversi porta al moltiplicarsi di interconnessioni rendendo questi sistemi più vulnerabili sia agli errori, sia ai cali di prestazioni, sia ad azioni fraudolente. Per questo si parla di una vera e propria crisi della complessità del software [34]. Questa complessità sta diventando il fattore limitante nello sviluppo futuro. Inoltre l impiego di reti di elaboratori su larga scala per la comunicazione ed il calcolo favorisce l uso di applicazioni distribuite eterogenee in cui i singoli elementi si occupano di una moltitudine di differenti task, che possono spaziare, ad esempio, dai processi per il controllo interno, alla presentazione di contenuti Web, alla gestione supporto per il cliente. In aggiunta questo scenario è reso più complesso dall uso sempre più diffuso dei dispositivi mobili; non sono più rari i casi di dipendenti che comunicano da remoto con i sistemi aziendali usando laptop, PDA o telefoni cellulari, ciascuno basato su differenti tecnologie. Questa complessità è difficilmente controllabile da parte di operatori umani. Il controllo manuale richiede tempo, è costoso e soggetto ad errori, inoltre lo sforzo legato a questo tipo di controllo tende ad incrementarsi molto velocemente. Una delle soluzioni proposte per fronteggiare tutto ciò ha preso spunto dalla capacità del sistema nervoso autonomo umano di auto-gestirsi. È nato così un nuovo filone di ricerca, fortemente finanziato dalla IBM, quello dei sistemi di tipo

7 1 I sistemi di tipo autonomic 6 autonomic. L Autonomic Computing vuole affrontare la complessità tecnologica utilizzando la tecnologia stessa, cioè inserendo nei sistemi moduli in grado di renderli autonomi nelle aree della configurazione, dell ottimizzazione, della riparazione e della sicurezza [7, 34, 74]. I principi dell autonomic computing, ed il termine stesso autonomic, derivano dalla medicina, si sta tentando, cioè, di imitare il sistema nervoso autonomo che sovrintende alle funzioni vitali dell organismo umano di cui la persona non ha coscienza, come ad esempio il battito cardiaco. Allo stesso modo, le capacità autonomic di auto-gestione cercano di anticipare le necessità del sistema informatico e risolvono problemi col minimo intervento umano possibile basandosi su schemi e politiche predefiniti. Uno degli ambiti in cui l approccio dell autonomic computing sembra più promettente è quello dei sistemi ad alta affidabilità e disponibilità. Figura 1.1. L Autonomic Computing concentra i propri sforzi in quattro aree: selfconfiguring, self-optimizing, self-healing e self-protecting. Queste funzioni di controllo vengono normalmente suddivise in quattro grandi categorie: auto-configurazione, auto-riparazione, autoottimizzazione ed auto-protezione (figura 1.1): Self-configuring: installare, configurare, ed integrare sistemi informatici complessi è un attività che, oltre ad essere dispendiosa in

8 1 I sistemi di tipo autonomic 7 termini di tempo, può essere particolarmente soggetta errore. I sistemi autonomic affrontano queste problematiche ripromettendosi di configurarsi automaticamente in accordo con politiche di alto livello. In questo modo nel momento in cui si introducono nuovi componenti il resto del sistema si adatterà alla loro presenza. Lo scopo di quest area dell autonomic computing è di fornire capacità di auto-configurazione all intera infrastruttura IT, non solo ai singoli elementi. Self-healing: l obiettivo di quest area è permettere ai sistemi di tipo autonomic di riconoscere, diagnosticare e rimediare ai problemi derivanti da malfunzionamenti software e hardware, tramite, ad esempio, un test di regressione. Utilizzando le conoscenze sulla configurazione di sistema, un componente per la diagnosi potrebbe analizzare le informazioni provenienti dai file di log, integrandole con dati ricavati da altre fonti. Il sistema, poi, farà corrispondere le patch software conosciute coi risultati di diagnosi e installerà quella appropriata Self-optimizing: i middleware complessi possono avere centinaia di parametri che devono essere settati correttamente affinché il sistema sia eseguito in maniera ottimale. Di solito, inoltre, questi sono integrati con altri ugualmente complessi. Di conseguenza, il performance-tuning di un sotto-sistema può causare effetti non previsti sull intero sistema. I sistemi autonomic si propongono di ricercare modi per migliorare le proprie prestazioni, identificando e fissando le opportunità di rendere se stessi più efficienti dal punto di vista delle performance o dei costi. Auto-ottimizzazione, può significare anche riallocazione di risorse in risposta a cambiamenti dinamici nel carico di lavoro. Self-protecting: quest area dell autonomic computing si ripropone di anticipare, rilevare, identificare, e proteggersi dai comportamenti ostili. I sistemi dovrebbero rilevare minacce appena esse si verifichino ed eseguire azioni correttive che li rendano meno vulnerabili. I comportamenti ostili in questo contesto, possono includere, ad esempio, accessi ed utilizzi non autorizzati o l infezione e la proliferazione di virus.

9 1.1 L architettura di riferimento 1.1 L architettura di riferimento 8 Nell architettura di riferimento proposta dalla IBM, [30], i sistemi di tipo autonomic possono essere visti come delle raccolte di elementi a loro volta autonomic, ciascuno dei quali conterrà risorse ed erogherà servizi per gli altri elementi del sistema. Ciascuno di essi tenta di operare il più possibile localmente, richiedendo l attenzione ai livelli più alti solo se necessario. Un singolo elemento autonomic consiste di una o più risorse gestite, associate ad un singolo gestore che le controlla e le rappresenta. L elemento gestito sarà in buona sostanza, equivalente a ciò che si può trovare in un normale sistema non autonomic con la possibilità di monitorarlo e controllarlo attraverso un autonomic manager. La distinzione tra autonomic manager e risorsa gestita potrebbe divenire puramente concettuale piuttosto che architettonica, oppure scomparire, cedendo il passo ad elementi autonomic completamente integrati con funzionamenti ed interfacce ben definite, ma anche con qualche vincolo sulla struttura interna. Ogni elemento autonomic sarà responsabile della gestione del proprio funzionamento e del proprio stato interno, nonché della gestione delle sue interazioni con un ambiente composto in gran misura da segnali e messaggi provenienti dagli altri elementi e dal mondo esterno. Il suo funzionamento interno e le relazioni con gli altri saranno guidati dagli obiettivi che il suo progettista ha prefissato, dagli altri elementi che hanno autorità su di esso, o dalle commesse degli elementi di pari grado col suo consenso tacito o esplicito. Un elemento, come già detto, potrebbe richiedere assistenza agli altri al fine di realizzare i propri scopi. In questo caso, esso si assumerebbe la responsabilità di ottenere le risorse necessarie dagli altri elementi, e di trattare i casi eccezionali, come il guasto di una risorsa richiesta. Ai livelli più bassi, il range di funzionamenti e relazioni dell elemento, e l insieme di elementi con cui esso interagisce, potrebbe essere relativamente limitato e codificato. Su questi presupposti un sistema di calcolo autonomic viene organizzato nei layer e nelle parti mostrate nella figura 1.2 [54]. Queste parti sono connesse utilizzando un enterprise service bus che consente ai componenti di collaborare utilizzan-

10 1.1 L architettura di riferimento 9 do meccanismi standard come i Web Services. L enterprise service bus integra vari blocchi. Touchpoint per le risorse gestite; Basi di conoscenza; Autonomic Manager; Manual Manager. Figura 1.2. Architettura di riferimento dell Autonomic Computing. Il livello più basso contiene i componenti del sistema, o risorse gestite (managed resources), che costituiscono l infrastruttura IT. Queste managed resources possono essere qualsiasi tipo di risorsa (hardware o software) e potrebbero avere attributi di self-managing embedded. Il livello successivo incorpora interfacce consistenti e standard alla gestione per l accesso ed il controllo delle managed resources. Queste interfacce standard sono fornite tramite i touchpoint. I livelli superiori automatizzano alcune porzioni del processo IT utilizzando un autonomic manager. Una particolare risorsa dovrebbe avere uno o più touchpoint autonomic manager, ciascuno dei quali

11 1.1 L architettura di riferimento 10 implementa il loop di controllo relativo. Il terzo livello dal basso nella figura 1.2, illustra ciò descrivendo un autonomic manager per le quattro categorie introdotte in precedenza (self-configuring, self-healing, self-optimizing e self-protecting). Il quarto livello contiene gli autonomic manager che orchestrano gli altri autonomic manager. E questa orchestrazione a fornire le capacità autonomic a tutto il sistema incorporando i loop di controllo che hanno la visione più ampia di tutta l infrastruttura IT. Il livello più alto illustra i manager manuali (Manual Manager) che forniscono un interfaccia di gestione del sistema comune per gli operatori utilizzando una consolle integrata. I vari manager, autonomic e manual, possono ottenere e condividere la conoscenza attraverso le basi di conoscenza (knowledge sources). Un autonomic manager automatizza alcune funzioni di management in accordo con le politiche definite attraverso l interfaccia di gestione. L autonomic manager implementa il loop di controllo mostrato in figura 1.3: La funzione di monitoraggio fornisce i meccanismi per raccogliere, aggregare, filtrare e fornire il resoconto dei dettagli collezionati da una risorsa gestita. La funzione di analisi fornisce i meccanismi per correlare e modellare situazioni complesse. Tali meccanismi consentono ai manager di avere capacità di apprendimento sull ambiente IT ed aiutano a predire situazioni future. La funzione di pianificazione fornisce i meccanismi per la costruzione delle azioni necessarie al raggiungimento degli obiettivi. La funzione di esecuzione fornisce i meccanismi che controllano l esecuzione del piano con la possibilità di effettuarne l aggiornamento. Le quattro funzioni consumano e generano conoscenza. Questa è continuamente condivisa in modo tale che le decisioni possano esser prese grazie ad informazioni migliori. Un touchpoint di una risorsa gestita consente alle interfacce di sensori ed attuatori, che l autonomic manager usa, di interagire con una risorsa gestita. Una base di conoscenza è un implementazione di un repository che fornisce accesso alla conoscenza in accordo con le interfacce prescritte

12 1.1 L architettura di riferimento 11 Figura 1.3. Dettagli funzionali dell autonomic manager. dall architettura, condivise tra gli autonomic manager. La conoscenza può essere ottenute in tre modi diversi: 1. La conoscenza è passata all autonomic manager (es. politiche ed obiettivi); 2. La conoscenza è recuperata da una base di conoscenza esterna (es. conoscenze storiche di una risorsa); 3. L autonomic manager può creare conoscenza tramite la funzionalità di monitoraggio (che raccoglie le informazioni di una particolare risorsa attraverso i suoi sensori) o di esecuzione (che indica le azioni da prendere come risultato del monitoraggio e della pianificazione). Un touchpoint è un componente del sistema che espone lo stato e le operazioni di gestione per una risorsa del sistema. Un autonomic manager comunica con il touchpoint tramite l interfaccia di gestione (manageability interface). Il touchpoint è l implementazione dell in-

13 1.1 L architettura di riferimento 12 terfaccia di gestione per una specifica risorsa o un insieme di risorse gestibili. L interfaccia di gestione per controllare una managed resource è organizzata nelle interfacce dei suoi sensori ed attuatori. Il comportamento di sensori ed attuatori per una specifica risorsa viene realizzato, in un touchpoint, mappando le interfacce di sensori ed attuatori standard ad uno o più componenti dell interfaccia di gestione della risorsa. In questo modo la complessità dell interfaccia di gestione è ridotta, in quanto agli autonomic manager viene sempre offerta una interfaccia standard, sebbene i diversi componenti dell interfaccia sono associati a diversi tipi di risorse. Un sensore consiste in un insieme di proprietà che rendono disponibili informazioni sullo stato della risorsa accessibili attraverso operazioni get e un insieme di eventi di notifica nel caso in cui avvengono dei cambiamenti nello stato della risorsa che meritano attenzione. Un attuatore consiste in: un insieme di operazioni set, che consentono di cambiare lo stato della risorsa, ed un insieme di operazioni implementate dagli autonomic manager che consentono alla risorsa gestita di consultarsi con il suo manager. Sensori ed attuatori sono collegati tra loro. Per esempio, un cambiamento nella configurazione che avviene per mezzo dell attuatore dovrebbe riflettersi in una notifica di cambiamento di configurazione attraverso l interfaccia del sensore. Un manual manager è un implementazione dell interfaccia utente che consente ad un professionista IT di eseguire alcune funzioni di gestione manualmente. Il manual manager può collaborare con altri autonomic manager dello stesso livello o autonomic manager di orchestrazione. Il manual manager è la rappresentazione architetturale dell attività umana e tipicamente coinvolge un tecnico che utilizza una console di gestione. Un enterprise service bus è un implementazione che aiuta l integrazione di altri blocchi costitutivi (per esempio, autonomic manager e touchpoint) guidandone l interazione. Si può considerare ad esempio uno scenario di funzionamento di un autonomic manager. Si assume che ci sia un loop di controllo all inter-

14 1.1 L architettura di riferimento 13 no di un Web Server il cui obiettivo è di assicurare che l utilizzo della CPU non ecceda il 90%. Se la soglia viene superata, il sistema deve prendere dei provvedimenti. Il processo monitor è responsabile della raccolta e dell organizzazione dei dati. Una grossa fetta di conoscenza è fornita dalle informazioni di monitoraggio. E molto importante monitorare solo i dati che saranno utilizzati dal loop di controllo. Se, ad esempio, si memorizzano log di grandi dimensioni, le performance potrebbero essere deteriorate perchè sarebbero continuamente analizzati dati che non hanno alcuna rilevanza sul sistema. Un autonomic manager dovrà interrogare il sistema per vedere quale è l utilizzo della CPU e poi consegnare i dati all analyzer. L analyzer dovrà leggere i dati e determinare se è necessario fare qualcosa. Un cambiamento nell utilizzo della CPU fa sì che l analyzer invochi l oggetto di pianificazione per correggere il problema. Il ciclo di controllo è basato sulle policy; se una data condizione è soddisfatta deve essere eseguita un azione, in altri termini c è la necessità, di pianificare ed eseguire una risposta. Per l esempio riportato, la fase di pianificazione dell autonomic manager dovrà schedulare un azione di riavvio del server e vedere se ciò corregge il problema. Così come menzionato in precedenza, una grande quantità di conoscenza acquisita viene dal primo passo del ciclo di controllo: il monitoraggio. È importante considerare il tipo di dati che la conoscenza richiede. È semplice registrare tutte le transazioni che un Web Server produce, ma il tempo di elaborazione per estrapolare quei dati può avere un impatto eccessivo sul ciclo di controllo. Quando si assembla un sistema di calcolo autonomic, bisogna pianificare la conoscenza che deve essere registrata, che persistenza utilizzare e quali specifiche informazioni si stanno cercando. Non tutta la conoscenza richiesta, comunque, deriva da attività di monitoraggio; è possibile che un team di esperti progetti un insieme di scenari da aggiungere alla base di conoscenza del sistema. È anche possibile avere un database di sintomi ed azioni correttive. Per esempio, una rapida ricerca sul sintomo database server is down può avere come azione correttiva reboot the database server.

15 1.2 Livelli di maturità Livelli di maturità La maturità di un sistema autonomic è schematizzata in cinque livelli. Si parte dal livello base e si prosegue con quello gestito, predittivo, adattativo ed infine autonomic: Livello base: è il punto iniziale in un ambiente IT, ed il livello a cui si trovano alcuni sistemi IT oggi. Ogni elemento dell infrastruttura è gestito indipendentemente dall operatore che lo gestisce manualmente; Livello gestito: le tecnologie di gestione dei sistemi possono di solito raccogliere informazioni da fonti disparate, riducendo, man mano che aumenta la complessità dell ambiente, il tempo che l amministratore impiega a raccogliere e sintetizzare le informazioni; Livello predittivo: vengono introdotte nuove tecnologie per fornire correlazione tra i diversi elementi dell infrastruttura. Questi elementi possono cominciare a riconoscere procedure e a prevedere configurazioni ottimali; Livello adattativo: i sistemi stessi possono automaticamente eseguire l azione opportuna sulla base delle informazioni disponibili e della conoscenza su ciò che sta accadendo nel sistema; Livello autonomic: le operazioni dell infrastruttura sono governate da politiche ed obiettivi economici. Gli utenti interagiscono con la tecnologia autonomic per monitorare processi economici e modificare gli obiettivi.

16 2 La descrizione dei sistemi e la simulazione L obiettivo di questo lavoro è proporre una metodologia per rendere auto-ottimizzanti delle applicazioni informatiche. Si cerca di fare in modo, cioè, che un applicazione distribuita possa valutare autonomamente come configurarsi su un determinato sistema, quindi senza intervento esterno e basandosi essenzialmente sulla conoscenza che ha di se e del sistema che la ospita. Poiché le interazioni in programmi paralleli e distribuiti sono molto complesse da valutare analiticamente è stato scelto un approccio di tipo simulativo: l applicazione valuta l impatto che ha una determinata configurazione di parametri simulando un esecuzione. Per raggiungere l obiettivo di rendere un sistema autonomo dal punto di vista dell ottimizzazione delle prestazioni, si deve poterlo descrivere. È necessario, cioè, conoscere approfonditamente il sistema sia nelle sue singole parti sia nelle interazioni tra esse. Per questo è stato usato ed esteso un meta-linguaggio studiato per la descrizione di programmi paralleli: MetaPL [47, 48]. Mentre per ottenere la simulazione delle esecuzioni delle applicazioni è stato usato un simulatore di sistemi eterogenei: HeSSE [56]. Per entrambi è stata studiata un interfaccia Web Service in modo da facilitarne l integrazione in sistemi SOA. 2.1 MetaPL Il formato XML (Extensible Markup Language) è un formato per i file testuali derivato dallo Standard Generalized Markup Language (SGML, ISO 8879). I documenti XML sono fisicamente formati da

17 2.1 MetaPL 16 unità di memorizzazione chiamate entità, che possono contenere caratteri o altre entità. Logicamente un documento è composto da dichiarazioni, elementi, commenti caratteri e istruzioni di trasformazione ciascuno dei quali indicato esplicitamente da opportuni tag [70]. Ogni documento comincia con un entità radice. XSLT e XSL specificano un linguaggio per definire i fogli di stile per XML, vale a dire documenti di trasformazione. XSL include un vocabolario per specificare la formattazione e lo stile di un documento XML usando lo standard XSLT per specificare come un documento XML può essere trasformato in un altro [69]. Figura 2.1. Schema di principio del ciclo di vita dei documenti MetaPL. MetaPL è un linguaggio basato su XML per la descrizione di programmi paralleli. La sua caratteristica principale è l estensibilità, ottenuta sfruttando le caratteristiche di XML, mentre il suo scopo è di fornire un approccio unificato alla programmazione parallela, sia in fase di progettazione, sia nelle fasi successive. In particolare in questo lavoro, MetaPL sarà usato soprattutto dal punto di vista dell analisi e dell ottimizzazione delle prestazioni [47, 48]. È indipendente dal linguaggio di programmazione e può supportare diversi paradigmi di programmazione o librerie di comunicazione. Il nucleo centrale (core) può essere esteso tramite estensioni scritte

18 2.1 MetaPL 17 come DTD di XML, esse possono introdurre nuovi costrutti nel linguaggio. Nel seguito verranno descritte le estensioni sviluppate nell ambito di questa tesi. Il core definisce un piccolo insieme di elementi per le attività di base dei processi (cicli, switch, dichiarazione di variabili, creazione di processi...), mentre le estensioni definiscono ciò che caratterizzerà i programmi che si descrivono (si veda l appendice A). Sono state scritte infatti estensioni per le librerie a scambio di messaggi, per la memoria condivisa, per la programmazione object oriented. L uso effettivo di MetaPL è però basato sui concetti di Filtro e di Vista. Una vista è una descrizione del programma meno generale e più specifica; partendo da un documento MetaPL si possono ottenere, ad esempio, viste che siano diagrammi UML, documentazione in HTML o altri file MetaPL. La descrizione MetaPL, ha quindi lo scopo di concentrare in un unico documento strutturato, un insieme di informazioni legate ad un software esistente o in fase di progetto. Queste informazioni possono venire successivamente manipolate e raffinate per mettere in evidenza aspetti peculiari, o per usarle con software opportuni. Ogni nuova vista viene ottenuta applicando un insieme di filtri. Un filtro è un documento XSLT che genera una nuova vista a partire da un documento XML, ed è quindi strettamente legato ai propri DTD. La possibilità di applicarli deriva dalla strutturazione del linguaggio. Inoltre anche essi sono facilmente estensibili. In altri termini ogni DTD che definisce un estensione per MetaPL, indica quali sono gli elementi (tag) che è possibile usare e come usarli, cioè come annidarli negli altri tag e quali attributi inserire. Ogni filtro che fa riferimento a un DTD conosce quali sono questi elementi e come trasformarli in qualcos altro. Ad esempio ad un estensione che definisce un operazione di somma può corrispondere un filtro che deriva una funzione in linguaggio C corrispondente a quella descritta nel documento MetaPL. La figura 2.1 mostra come è possibile fare interagire tutti gli elementi appena descritti per sfruttarne le caratteristiche al fine di fare progettazione e analisi di programmi paralleli. Un documento Meta-

19 2.1 MetaPL 18 PL, che è un file testuale in formato XML, viene scritto basandosi su un insieme di estensioni, a loro volta implementate come file testuali in formato DTD (o XML Schema). Usando i filtri adatti (file testuali XSLT) una o più volte in cascata, il documento principale viene trasformato in nuove viste pronte da essere usate per lo sviluppo, l analisi, la simulazione o quanto altro le necessità dello sviluppatore detteranno. Operativamente per ottenere queste trasformazioni è possibile usare uno qualunque degli strumenti disponibili per validare e trasformare file XML. Nei test effettuati quello che ha permesso di ottenere i risultati migliori in termini di efficienza e potenzialità d uso, è stato Apache Ant. Pur essendo stato progettato esplicitamente per gestire progetti in linguaggio Java, esso offre facility per il trattamento dei documenti XML. In particolare integra i processori Xerces e Xalan [28, 65]. Per usare Ant è necessario scrivere un file di comandi in formato XML (build file), chiamato di solito build.xml, in cui viene riportata la sequenza dei comandi da eseguire. Tra le varie opzioni disponibili in questo strumento c è, appunto, la possibilità di usare trasformazioni xslt. Di seguito si mostra un frammento di build file di ant usato per applicare un filtro a del codice MetaPL: <? xml version =" 1.0 "?> <project name =" LogAnalysis - RAMPDS " default =" transform ">... <target name =" transform "> <xslt in=" Application / LogAnalysis. xml " out =" tmp / traces / LogAnalysis. view.1. xml " style =" Filters / oomethodunrolling. xsl "> < outputproperty name =" method " value =" xml "/> < outputproperty name =" standalone " value =" yes "/> < outputproperty name =" encoding " value =" iso8859_1 "/> < outputproperty name =" indent " value =" yes "/> </ xslt >

20 2.2 Estensioni per i Web Services 19 </ target >... </ project > 2.2 Estensioni per i Web Services Un Web Service è un interfaccia che descrive un insieme di operazioni, accessibili mediante messaggi in formato XML. La caratteristica distintiva dei Web Services rispetto agli altri tipi di strumenti e librerie per la programmazione distribuita, è l uso dello standard SOAP per la codifica dei messaggi, e dello standard WSDL (Web Services Description Language) per la definizione e la pubblicazione delle interfacce. Entrambi sono documenti in formato XML [8]. <! ELEMENT WebService ( wsmethod *) > <! ATTLIST WebService name CDATA # REQUIRED > <! ELEMENT wsmethod ( wsmethodmsgsize, ANY *) > <! ATTLIST wsmethod name CDATA # REQUIRED > <! ELEMENT wsmethodmsgsize (# PCDATA ) > <! ELEMENT wsremotework (# PCDATA ) > <! ELEMENT wsmethodcall (# PCDATA ) > <! ATTLIST wsmethodcall ws CDATA # REQUIRED > <! ATTLIST wsmethodcall name CDATA # REQUIRED > Figura 2.2. DTD che definisce le estensioni WS. L estensione per i Web Services permette la descrizione di interfacce remote e delle chiamate dei client a tali interfacce. Nella figura 2.2 è mostrato il DTD che definisce l estensione, sono presenti quattro elementi [38]: WebService è l elemento che identifica l intero Web Service; wsmethod indica un singolo servizio e contiene la logica del servizio stesso; wsmethodmsgsize indica le dimensioni del messaggio;

21 2.2 Estensioni per i Web Services 20 wsremotework indica il carico legato all esecuzione del servizio; wsmethodcall indica una chiamata ad un servizio già definito. <? xml version =" 1.0 " encoding =" ISO_8859-1" standalone =" yes "?> < xsl: transform version =" 1.0 " xmlns:xsl =" http: // /1999/ XSL / Transform "> < xsl:output method =" text " indent ="no" standalone =" yes "/> < xsl:template match ="*" > < xsl:apply - templates / > </ xsl:template > < xsl: template match =" WebService " > <xsl:value -of select " /> < xsl:text > </ xsl:text > <xsl:value -of select "/> </ xsl:template > < xsl: template match =" classmodule " > </ xsl:template > < xsl: template match =" Task " > </ xsl:template > < xsl:template match =" wsmethod "> </ xsl:template > </ xsl: transform > Figura 2.3. Esempio di trasformazione XSLT basata sull estensione per Web Services. Accanto al DTD sono stati definiti una serie di filtri. In figura 2.3 e 2.4 ne sono mostrati due che gestiscono rispettivamente i Web Services ed i servizi. Nel primo caso il filtro estrae semplicemente l elenco dei Web Services riferiti da un documento MetaPL, nel secondo vengono analizzati i servizi offerti e vengono riportate alcune informazioni (nome, carico e dimensioni) che saranno utilizzate come traccia in una simulazione Esempio Le figure 2.5 e 2.6 mostrano un esempio della descrizione MetaPL di un Web Service, mentre la figura 2.7 mostra un frammento di

22 2.2 Estensioni per i Web Services 21 <? xml version =" 1.0 " encoding =" ISO_8859-1" standalone =" yes "?> < xsl: transform version =" 1.0 " xmlns:xsl =" http: // /1999/ XSL / Transform "> < xsl:output method =" text " indent ="no" standalone =" yes "/> < xsl:template match ="*" > < xsl:apply - templates / > </ xsl:template > < xsl: template match =" WebService " > < xsl:apply - templates / > </ xsl:template > < xsl: template match =" classmodule " > </ xsl:template > < xsl: template match =" Task " > </ xsl:template > < xsl:template match =" wsmethod "> <xsl:value -of select " /> < xsl:text > </ xsl:text > <xsl:value -of select "/> < xsl:text > </ xsl:text > <xsl:value -of select "/> </ xsl:template > </ xsl: transform > Figura 2.4. Esempio di trasformazione XSLT basata sull estensione per Web Services codice della descrizione di un client. L applicazione di esempio, chiamata LogAnalysis, è un tool per l analisi dei log che verrà descritto approfonditamente nel capitolo 4.1. Per la prototipizzazione di LogAnalysis viene scritta inizialmente una singola classe (figura 2.5), che sarà il back-end del Web Service finale. La classe LogAnalysisImpl viene progettata in questo contesto usando un ulteriore estensione MetaPL per la programmazione orientata agli oggetti. Nel frammento mostrato vengono riportati i soli nomi e il tipo dei metodi disponibili. Ognuno dei metodi della classe LogAnalysisImpl viene quindi mappato direttamente su un servizio del Web Service LogAnalysis (figura 2.6) usando il tag methodcall. Poiché la chiamata ad un servizio web è un operazione complessa e dispendiosa, nel modello bisogna tener conto anche dei dati scambiati e del carico dovuto allo

23 2.3 Estensioni per i sistemi di tipo autonomic 22 < classmodule name =" loganalysis " > < class name =" LogAnalysisImpl " > < description > Test bed for WS traces. </ description > < method name =" LogAnalysisImpl " type =" void " access =" public " /> < method name =" getlogrow " type =" String " access =" public " /> < method name =" findaddresses " type =" String []" access =" public " /> <method name =" renew " type =" void " access =" public "/> </ class > </ classmodule > Figura 2.5. Descrizione MetaPL dell interfaccia di un applicazione basata su Web Services. stack di chiamata SOAP. Questi vengono dichiarati esplicitamente con wsmethodmsgsize e wsremotework, in quando i singoli messaggi possono venire arricchiti dall applicazione che li spedisce a seconda delle proprie esigenze. Infine il client dell applicazione web di figura 2.7, viene descritto come una normale applicazione MetaPL, inserendo delle chiamate WSCall descritte nell estensione Web Services. Nel caso specifico vengono eseguite dieci iterazioni di tre chiamate consecutive ai servizi di LogAnalysis. 2.3 Estensioni per i sistemi di tipo autonomic Nello sviluppo delle estensioni di MetaPL per i sistemi autonomi è stato considerato principalmente l uso che ne è stato fatto nel framework MAWeS (capitolo 3) [42 44]. Quindi più che descrivere in dettaglio tutti i vari aspetti da tenere in conto quando si progetta un sistema autonomo, si sono privilegiati i punti che riguardano l autoottimizzazione, ed in particolare l individuazione dei parametri di cui ricercare i valori migliori, e la specifica dei loro domini e dei vincoli da imporre. Nella figura 2.8 è riportato il DTD dell estensione, in esso vengono specificati cinque elementi: Autonomic: è l elemento che raggruppa l estensione;

24 2.3 Estensioni per i sistemi di tipo autonomic 23 < WebService name =" LogAnalysis " > < wsmethod name =" stub " type =" void "> < wsmethodmsgsize > 100 </ wsmethodmsgsize > < methodcall module =" loganalysis " class =" LogAnalysisImpl " name =" getlogrow " / > < wsremotework time =" 150 " /> </ wsmethod > < wsmethod name =" getlogrow " type =" String "> < wsmethodmsgsize > 100 </ wsmethodmsgsize > < methodcall module =" loganalysis " class =" LogAnalysisImpl " name =" getlogrow " / > < WSremotework time =" 150 " /> </ wsmethod > < wsmethod name =" findaddresses " type =" String " > < wsmethodmsgsize > 100 </ wsmethodmsgsize > < methodcall module =" loganalysis " class =" LogAnalysisImpl " name =" getlogrow " / > < WSremotework time =" 150 " /> </ wsmethod > < wsmethod name =" renew " type =" void "> < wsmethodmsgsize > 100 </ wsmethodmsgsize > < methodcall module =" loganalysis " class =" LogAnalysisImpl " name =" getlogrow " / > < WSremotework time =" 150 " /> </ wsmethod > </ WebService > Figura 2.6. Descrizione MetaPL di un applicazione basata su Web Services. <Task > <Loop start ="1" end ="10"> <Task > <WSCall ws=" LogAnalysis " method =" stub " /> < WSlocalworktime time =" 1" / > <WSCall ws=" LogAnalysis " method =" renew " /> < WSlocalworktime time =" 1" / > < WSCall ws =" LogAnalysis " method =" getlogrow " / > < WSlocalworktime time =" 150 " / > <WSEnd /> </ Task > </ Loop > </ Task > Figura 2.7. Descrizione MetaPL di un client di Web Services.

25 2.3 Estensioni per i sistemi di tipo autonomic 24 Parameter: indica quali sono i parametri da considerare nell ottimizzazione, e permette di specificarne il dominio; Value: se il parametro può assumere solo un numero limitato di valori questi vengono specificati nell elemento Value; Constrain: indica un vincolo tra i parametri, viene specificato come un espressione booleana cha ha come operando i nomi dei tag Parameter. Target: indica l elemento da considerare nell analisi dell output del simulatore. Quest estensione non è stata progettata per l uso con i filtri standard di MetaPL, quanto per l uso in congiunzione con il framework MAWeS. <! ELEMENT Autonomic ( Parameter *, Constrain *, Target ) > <! ELEMENT Parameter ( Value *) > <! ELEMENT Constrain (# PCDATA ) > <! ELEMENT Value (# PCDATA ) > <! ELEMENT Target (# PCDATA ) > <! ATTLIST Parameter name CDATA # REQUIRED > <! ATTLIST Parameter type CDATA # IMPLIED > <! ATTLIST Parameter min CDATA # IMPLIED > <! ATTLIST Parameter max CDATA # IMPLIED > Figura 2.8. DTD per le estensioni autonomic di MetaPL. L esempio di un istanza del DTD è riportato in figura 2.9, dove sono indicati tre parametri per l ottimizzazione e viene impostato un vincolo. Si presuppone che il programma possa funzionare solo con 4, con 6 o con 10 processi utilizzando contemporaneamente 2 oppure 3 server usando due tipi di politica (statica e dinamica) per un totale di 12 configurazioni possibili. Nell esempio è inoltre presente un vincolo che impone che il numero di processi attivabili nell applicazione debba essere doppio di quello dei server. In questo modo il numero di configurazioni possibili si riduce a 4 (2,4,static, 3,6,static, 2,4,dynamic, 3,6,dynamic).

26 2.4 HeSSE < Autonomic > < Parameter name =" NumberOfProcesses " > <Value >4</ Value > <Value >6</ Value > <Value >10 </ Value > </ Parameter > < Parameter name =" NumberOfServers " > <Value >2</ Value > <Value >3</ Value > </ Parameter > < Parameter name =" ServerChoicePolicy " > <Value >Static </ Value > <Value > Dynamic </ Value > </ Parameter > < constrain > NumberOfProcesses = NumberOfServers * 2 < constrain > </ Autonomic >... Figura 2.9. Frammento di un documento MetaPL in cui sono evidenziate le estensioni autonomic. 2.4 HeSSE HeSSE (Heterogeneous S ystem S imulation E nvironment) è uno strumento orientato alla simulazione di un applicazione per un ampia gamma di tipi di sistemi distribuiti e con differenti carichi di rete e computazionali. Risponde, cioè, all esigenza di predire e valutare il comportamento di un applicazione quando questa viene usata in diversi ambienti e con diverse condizioni [38, 50, 51]. L approccio modulare di HeSSE permette di descrivere sistemi distribuiti eterogenei connettendo componenti semplici [4]. Ogni componente riproduce i comportamenti (dal punto di vista prestazionale), di una parte del sistema ad un dato livello di dettaglio. Ogni componente deve riprodurre comunque il comportamento funzionale e temporale del sottosistema che rappresenta, intendendo come comportamento funzionale l insieme dei servizi esportati agli altri componenti (che da essi possono essere richiesti), e come comportamento temporale il

27 2.4 HeSSE 26 tempo speso nell esecuzione di tali servizi. La modellazione viene fatta in primo luogo a livello di architettura. Ad esempio le prestazioni del livello fisico come quelle di un determinato tipo di processore, può venire descritta con semplici modelli analitici o tramite simulazione comportamentale, cioè tenendo conto del tempo totale di calcolo senza considerare il comportamento delle singole istruzioni. HeSSE usa le tracce per descrivere le applicazioni. Una traccia è un file che registra tutte le azioni di un programma che sono rilevanti per la simulazione. Per esempio la traccia per un applicazione MPI è una sequenza di burst di CPU e richieste all ambiente di run-time [41]. Ogni traccia è la rappresentazione di una specifica esecuzione di un programma parallelo. I file di traccia sono descrizioni di un applicazione orientate all applicazione, tipicamente vengono ottenute dalla modifica dell applicazione. Quando l applicazione non è disponibile, perchè ad esempio non è stata ancora sviluppata, possono essere generati a partire da meta-codice, come ad esempio MetaPL, cui si è accennato precedentemente. Figura Schema di una sessione di simulazione con HeSSE.

28 2.4 HeSSE 27 Il processo di analisi e simulazione per una data applicazione può essere rappresentato schematicamente come in figura La fase di descrizione di un sistema si evolve in tre passi: Descrizione dell applicazione: produzione del codice MetaPL; Modello dell architettura: definizione del modello dell architettura del sistema; Calibrazione del modello: valutazione dei parametri temporali. La descrizione di un applicazione consiste essenzialmente nello sviluppo di prototipi in MetaPL in modo da generare tracce necessarie per simulare un esecuzione. La definizione di un modello, quindi, consiste nella scelta o nello sviluppo di componenti HeSSE che saranno composti in un file di configurazione. Una volta fatto ciò è possibile riprodurre l evoluzione del sistema. L ultimo passo consiste nell ottimizzazione del modello eseguendo dei benchmark sul sistema di destinazione in modo da inserire le informazioni temporali nel simulatore e nelle descrizioni MetaPL L uso del simulatore HeSSE Operativamente il simulatore viene usato scrivendo tre file di configurazione: Libs.HeSSE: che specifica le librerie del simulatore da utilizzare (figura 2.12); Config.HeSSE: che specifica gli elementi coinvolti nella simulazione e come questi vengono connessi (figura 2.13); Commands.HeSSE: che specifica comandi addizionali associati a ciascun elemento specificato in Config.HeSSE, e caratteristici dell implementazione dell elemento stesso (figura 2.14). Ogni elemento è caratterizzato da un identificatore numerico univoco indicato da CID (Component Identifier) nei file di configurazione. Ciascun elemento che definisce un sistema da simulare è quindi definito nel file Config.HeSSE attraverso il proprio tipo (presente nelle librerie) e attraverso il CID insieme alle connessioni tra con gli altri elementi (tag Connect in figura 2.13). A seconda del tipo ad ogni componente

29 < HeSSEtrc > <! -- simulator output -- > < Configure >... </ Configure > 2.5 Interfacce Web Service per i tools 28 <! -- configuration steps -- > < StartAll > <! -- simulation components to be started -- > < StartComponent =" MPM_Interface " ID="10" time ="0"/> </ StartAll > <! -- events in the simulated run -- > < Simulation > < createprocess ID="14" com =" MPM_App " time =" 0.01 "/>... < MPM_Broadcast ID="16" com =" MPM_App " time =" "/>... <End ID="26" com =" MPM_App " time =" " /> </ Simulation > <! -- simulation closure steps -- > < Deconfigure >... </ Deconfigure > </ HeSSEtrc > Figura Frammenti dell output di HeSSE. possono essere associati uno o più comandi nel file Commands.Hesse (figura 2.14). Node.dl Ethernet. dl EthDriver. dl PKT.dl MPM.dl Web.dl Figura Esempio di file Libs.HeSSE. 2.5 Interfacce Web Service per i tools Le descrizioni MetaPL e le simulazioni HeSSE rendono possibile analisi delle prestazioni tali da identificare i colli di bottiglia e configu-

30 2.5 Interfacce Web Service per i tools 29 Component CID 10 MPM_ Interface EndComponent Component CID 11 SMP_ Node EndComponent... Component CID 14 WebServer EndComponent Component CID 16 WebService EndComponent Component CID 1 Eth_ Switch EndComponent Component CID 2 MPM_ Data EndComponent Connect CID 13 PIN 1 CID 11 PIN 1 EndConnect Connect CID 12 PIN 1 CID 13 PIN 2 EndConnect... EndConfig Figura Frammento di file Config.HeSSE. rare di conseguenza sia i sistemi sia le applicazioni finali. Oltre all uso tramite linea di comandi ed interfaccia grafica [39], questi strumenti sono stati provvisti di un interfaccia Web Service che incapsula i servizi di descrizione, simulazione e analisi. Queste interfacce possono essere sfruttate da coloro che voglio accedere da remoto al simulatore o integrate in programmi che possono usarle per automatizzare i processi di analisi delle prestazioni.

31 Command SetTID CID 16 TID long 1 EndCommand Command Schedulable CID 10 Mode string false EndCommand Command Schedulable CID 20 Mode string false EndCommand Command SetDaemonPar CID 10 tp0 double e -12 tp1 double e -05 tp2 double e -01 tp3 double EndCommand Command SetDaemonPar CID 20 tp0 double e -12 tp1 double e -05 tp2 double e -01 tp3 double EndCommand Interfacce Web Service per i tools 30 Figura Frammento di file Commands.HeSSE HeSSEws HeSSE prende in input una serie di file di testo, producendo un file XML con gli eventi del modello simulato. Il Web Service HeSSEws permette di usare il simulatore da remoto, gestendone sia l esecuzione (runsimulation), sia l ambiente (operazioni su file e directory). Il modo in cui HeSSEws opera è descritto nel diagramma di sequenza di figura WS App rappresenta l applicazione che usa i servizi proposti. In prima istanza prepara l ambiente di simulazione creando una cartella di simulazione copiando i file necessari ed avviandovi la simulazione. Quando questa termina l applicazione web può richiedere il file XML che contiene il risultato (un frammento è riportato nella figura 2.11). L output di HeSSE è contenuto tra i tag <HeSSEtrc> </HeSSEtrc>,

32 2.5 Interfacce Web Service per i tools 31 ed è composto da diverse sezioni (elementi XML). I tempi calcolati dal simulatore sono raccolti dai tag Simulation, quindi, ad esempio, il tempo di esecuzione di un processo può essere ottenuto analizzando tale file. Figura Diagramma di sequenza di una sessione di simulazione usando l interfaccia basata su Web Services. HeSSEtrc è l elemento radice che contiene tutto l output di HeSSE; Configure è l elemento che descrive i passi compiuti duranti la configurazione della simulazione; StartAll è l elemento che indica l inizio della simulazione in tutti i componenti; Simulation contiene la sequenza di elementi che registrano le azioni di tutti i componenti durante la simulazione. Ciascun elemento corrisponde ad un azione, l attributo com indica il tipo di componente del simulatore, ID è un identificatore univoco del componente, time è il timestamp dell evento; Deconfigure è l elemento che descrive i passi compiuti durante il termine della simulazione. Tabella 2.1. Elenco dei tag principale usati nell output di HeSSE MetaPLws MetaPL opera su un insieme di file: documenti MetaPL, schema o DTD di XML, filtri e viste finali. Quindi il Web Service MetaPLws offre una serie di servizi che permettono di operare su essi. MetaPLws pubblica il servizio chiamato applyfilter, che applica un filtro ad un

33 2.5 Interfacce Web Service per i tools 32 documento MetaPL, ed execute, che esegue uno script (tipicamente una sequenza di filtri). La sintassi di questo sarà descritta nel capitolo seguente in quanto tutto il supporto al ciclo di vita dei documenti MetaPL è stato integrato nel framework MAWeS. Figura Diagramma di sequenza dell applicazione di filtri MetaPL.

34 3 L auto-ottimizzazione HeSSE e MetaPL permettono agli utenti di analizzare le prestazioni di un sistema, visto come insieme di software ed hardware, senza avviarne l esecuzione, e quindi, potenzialmente, quando si è ancora in fase di progetto. Inoltre, usati sinergicamente, semplificano l esplorazione di soluzioni alternative che offrono risultati più o meno validi, dando la possibilità di valutare rapidamente l uso di un applicazione in situazioni e su architetture diverse. Si può, ad esempio, valutare l impatto di una variazione del carico di rete su un applicazione distribuita. La velocità di simulazione, relativamente ad un esecuzione reale apre le porte alla possibilità di cercare a run-time le configurazioni migliori, intese come combinazioni migliori di parametri. Un software può quindi valutare lo stato del sistema che lo ospita ed il proprio stato, e quindi configurarsi in modo da migliorare le proprie prestazioni o ottimizzare l uso delle risorse. Conoscendo l architettura ed il software, si possono individuare una serie di parametri su cui il software ha il controllo che possono influenzarne le prestazioni, ad esempio su quanti processi dividere un compito, o quali macchine usare per un calcolo distribuito; per ognuno di tali parametri si può, quindi, individuare un dominio e porre dei vincoli. Ad esempio se si scelgono come parametri il numero m di macchine da utilizzare ed il numero p di processi da attivare, si può porre come dominio di m gli interi da 1 al numero di macchine disponibili (es. m [ ]), e come vincolo che ogni macchina abbia due processi attivi (p = 2m).

35 3.1 MAWeS 34 Allo scopo di studiare ed affrontare quanto appena esposto è stato sviluppato un framework che, integrandosi con il simulatore HeSSE, e sfruttando MetaPL, permette alle applicazioni che ne fanno uso di valutare le configurazioni di esecuzione ottimali, una volta che si conosca il sistema e le condizioni in cui questo si trova, siano esse misurate o presunte. Questo framework, chiamato MAWeS (MetaPL/HeSSE Autonomic Web Services), è stato progettato basandosi sugli standard dei servizi web in modo da sfruttarne le caratteristiche di interoperabilità, tenendo presente che l overhead delle comunicazioni SOAP è comunque trascurabile se paragonabile al tempo consumato nelle simulazioni iterative (figura 3.1) [8, 53]. Figura 3.1. Impatto della gestione e dell invio dei messaggi sul tempo di chiamata del servizio La possibilità di usare dati misurati o stimati per lo stato dei sistemi, apre la strada all ottimizzazione preventiva delle applicazioni: se un applicazione prevede un picco di carico per un determinato istante, può valutarne gli effetti preventivamente tramite simulazione, e quindi capire quale è la configurazione migliore per la situazione che si aspetta. È questo, ad esempio, il caso di un applicazione che fa streaming video, per cui si possono prevedere picchi di traffico a determinate ore. Si affronta in questo modo il problema dell ottimizzazione delle prestazioni da un punto di vista feedforward, di anticipazione, piuttosto che feedback, di reazione [43, 51, 60]. 3.1 MAWeS Nello studio e nello sviluppo del framework MAWeS si è voluto provare come fosse possibile automatizzare i processi di simulazione e predi-

36 3.1 MAWeS 35 Figura 3.2. Casi d uso del framework MAWeS. zione delle prestazioni in modo da sviluppare sistemi che si autoottimizzino. MAWeS offre i servizi di gestione del ciclo di vita dei documenti MetaPL, la gestione delle simulazioni HeSSE ed il sistema di ricerca delle configurazioni migliori (figura 3.2). All utente è demandato il compito di creare una descrizione dell hardware e del software, nonché di impostare una serie di filtri, scegliendoli, estendendoli o scrivendoli. Questi devono permettere di ottenere dei file di traccia usabili nelle simulazioni. L hardware e una parte dello strato software (ad esempio le librerie MPI) vengono invece descritti mediante file di configurazione di HeSSE. Il framework MAWeS è logicamente strutturato in tre livelli (figura 3.3): Frontend: permette l accesso ai servizi di MAWeS da parte dei client. Più che all aggiunta di funzionalità, questo modulo è preposto alla semplificazione dell uso dei servizi disponibili da parte dei moduli server; Core: è composto dai moduli che prendono le decisioni di ottimizzazione e coordinano le simulazioni e la generazione delle tracce;

37 3.2 L architettura di MAWeS 36 Interfacce WS: è l insieme dei Web Services usati per ottenere le simulazioni e le predizioni attraverso l uso di MetaPL e HeSSE. Figura 3.3. Schema della struttura logica di MAWeS. Attualmente il frontend di MAWeS fornisce un interfaccia, chiamata MAWeSclient, specifica per il linguaggio Java, che può essere estesa dalle applicazioni che vogliono usare il framework. Essa accetta in input un insieme di file che descrivono l applicazione in formato MetaPL (arricchito con le estensioni autonomic descritte nella sezione 2.3) ed il sistema ospite nel formato dei file di configurazione di HeSSE. Il Core di MAWeS sfrutta i servizi del sistema sottostante e dei moduli di gestione MetaPL/HeSSE per cercare le condizioni di esecuzione ottimali, per far ciò usa le informazioni contenute in questi file. 3.2 L architettura di MAWeS L activity diagram di figura 3.4 mostra le azioni che vengono effettuate durante l ottimizzazione dell esecuzione di un servizio. Queste azioni vengono inquadrate nei blocchi logici che compongono l applicazione ed il framework. Inizialmente il client applicativo richiede un servizio.

38 3.2 L architettura di MAWeS 37 Figura 3.4. Activity diagram del framework MAWeS

39 3.2 L architettura di MAWeS 38 Questo viene eseguito sull host che indicato nella richiesta, e, a seconda di come è stato configurato, avvia immediatamente o durante la propria esecuzione, il servizio di ottimizzazione. Questo può essere avviato in modo sincrono, ed è il caso di ottimizzazioni fatte nel momento della chiamata, o asincrono nel caso di ottimizzazioni avviate in seguito al variare delle condizioni del sistema. La richiesta del servizio di ottimizzazione avviene tramite il modulo MAWeSclient, che si occupa di inviare al core tutti i file necessari. Trattandosi di diversi documenti, che possono essere anche strutturati in directory, MAWeSclient li comprime con un algoritmo LZW standard e li invia al Web Service come attachment SOAP [53]. A questo punto il core estrae tutti i documenti dal messaggio, e comincia ad applicare i filtri indicati (con la modalità mostrata nella sezione successiva) in modo da produrre un insieme di tracce corrispondenti a configurazioni diverse del sistema. Ogni volta che questi filtri vengono applicati, il foglio di stile viene parametrizzato, usando i valori ottenuti dai parametri della descrizione MetaPL. Per ognuna delle configurazioni ottenute viene avviata una simulazione HeSSE, e vengono raccolti i risultati con i tempi di esecuzione. Alla fine, tra tutte le configurazioni simulate viene scelta quella con i tempi di esecuzione minori e restituita al client che ha avviato la richiesta di ottimizzazione. Il framework è organizzato in tre aree che ricalcano i casi d uso mostrati in figura 3.2. Queste tre aree corrispondono, nell implementazione a tre packages in linguaggio Java: core, metafilter e services (figura 3.5). Il package services contiene le interfacce ai motori simulativo e di filtraggio. Il package metafilter contiene il motore MetaPL, è quindi l implementazione del sistema di filtri e di script necessario per produrre le tracce di simulazione. Mentre il package core contiene la logica di gestione di MAWeS, quindi la generazione delle configurazioni, la coordinazione del filtraggio e delle simulazioni, la gestione delle aree di elaborazione temporanee e la gestione dei messaggi verso i client.

40 3.2 L architettura di MAWeS 39 Figura 3.5. Diagramma delle classi principali di MAWeS La gestione delle simulazioni: il package core La classe principale del core di MAWeS è la classe MAWeScore di cui di seguito si riporta un frammento. All interno di questa classe il metodo fondamentale è il metodo execute. Questo prende in input il pacchetto compresso contenente tutti i file che descrivono l applicazione e i riferimenti a quali sono i file MetaPL e di gestione dei filtri che dovranno essere presi in considerazione. public class MAWeScore { private static Log logger = LogFactory. getlog ( MAWeScore. class. getname ()); final MetaFilter metafilter ; final HeSSEParser hesseparser ; final HesseWrapper hessewrapper ; final MetaPLAutonomicParser metaplautopars ; public MAWeScore () throws Exception {... } public File execute ( File inzipf, String metaplflname, String scriptname ) throws Exception {...

41 3.2 L architettura di MAWeS 40 } } Di seguito è riportato un frammento dell algoritmo implementato nella funzione execute. Si può notare la sequenza delle azioni: impostazione dei valori dei parametri, valutazione dei vincoli, applicazione dei filtri, esecuzione delle simulazioni e valutazione dell output del simulatore. boolean someparmatermaychange = false ; do { final long t0 = System. currenttimemillis (); // Change parameter values... // Constrain while ( encon. hasmoreelements ()) { final String constrain = encon. nextelement (); final Evaluator e = new Evaluator ( constrain, enpar ); flag = flag && e. checkconstrain (); } if ( flag ) { // Apply filters if ( logger. isinfoenabled ()) logger. info ("[ MAWES CORE ] ("+ System. currenttimemillis ()+ ") Apply filters "); metafilter. execute ( sourcedir, scriptname, parameters ); // Execute HeSSE if ( logger. isinfoenabled ()) logger. info ("[ MAWES CORE ] ("+ System. currenttimemillis ()+ ") Start HeSSE simulation "); HesseWrapper. startsimulation ( sourcedir, ""); final File resultfile = new File ( sourcedir, MAWeS. props. getproperty (" hesse. outputfilename " )); if ( logger. isinfoenabled ()) logger. info ("[ MAWES CORE ] ("+ System. currenttimemillis ()+ ") End HeSSE simulation "); // Parse HeSSE output if ( logger. isinfoenabled ()) logger. info ("[ MAWES CORE ] Result analysis ("+ resultfile. getabsolutepath ()+ ")"); // Check if iterations must continue enpar = metaplautopars. params. elements (); while ( enpar. hasmoreelements () &&! someparmatermaychange ) { final Parameter p = enpar. nextelement (); someparmatermaychange = p. maychange (); }... } while ( someparmatermaychange );

42 3.2 L architettura di MAWeS La gestione dei servizi di secondo livello: Il package services La gestione degli strumenti di base (HeSSE e MetaPL) tramite interfaccia web è stata fatta con una semplice operazione di incapsulamento. In particolare di seguito viene riportato un frammento di codice estratto dalla classe che gestisce HeSSE: public class HeSSEwsImpl implements HeSSEws { private static Log logger = LogFactory. getlog ( HeSSEwsImpl. class. getname ());... public boolean startsimulation ( java. lang. String path ) throws java. rmi. RemoteException { if ( logger. istraceenabled ()) logger. trace (" startsimulation "); boolean out = false ; try { String env []={ " HeSSEBin ="+ properties. getproperty (" hesse. bin " )}; } } Runtime r= Runtime. getruntime (); Process p=r. exec (" properties. getproperty (" hesse. commandline "), env, new File ( path )); p. waitfor (); out = true ; } catch ( Exception e) { e. printstacktrace (); out = false ; if ( logger. iserrorenabled ()) logger. trace (" Hesse simulation failed : " +e. getmessage (), e); } return out ; La gestione dei filtri: il package metafilter L applicazione dei filtri è un operazione strettamente legata all applicazione che si sta modellando. È stata fatta, quindi, la scelta di descrivere la sequenza di filtri mediante uno script scritto in XML, il cui DTD è mostrato in figura 3.6. Questi script contengono un piccolo numero di elementi: metafilter è l elemento radice dello script; filter indica l applicazione di un filtro, si deve specificare il file a cui applicarlo, il file in ouptut e naturalmente il nome del filtro;

43 <? xml version =" 1.0 " encoding ="ISO "?> <! ELEMENT metafilter ( filter *, simulation ) > <! ATTLIST metafilter filterrepository CDATA # REQUIRED > 3.2 L architettura di MAWeS 42 <! ELEMENT filter ( echo *, param *) > <! ATTLIST filter in CDATA # REQUIRED out CDATA # REQUIRED filter CDATA # REQUIRED > <! ELEMENT echo (# PCDATA ) > <! ELEMENT param (# PCDATA ) > <! ATTLIST param name CDATA # REQUIRED type ( string int float ) " string " > <! ELEMENT simulation (# PCDATA ) > <! ATTLIST simulation hessebin CDATA # REQUIRED > Figura 3.6. DTD degli script di filtraggio. echo permette di inserire un messaggio definito dall utente nel file di log; param indica il nome dei parametri il cui valore sarà ricavato esternamente dal foglio di stile; simulation è un elemento opzionale che permette di avviare una simulazione direttamente dallo script. In generale questo tipo di script specificano quali filtri applicare, a quali file farlo e l ordine in cui applicarli. Inoltre è in questi script che deve essere esplicitamente attivata la simulazione, in modo da poter dare la possibilità di applicare ulteriori filtri anche all output del simulatore, nel caso in cui l utente decida che questo sia utile. La figura 3.7 mostra un esempio molto semplice di script che si uniforma a questo schema. Al documento MetaPL nbody.xml vengono

44 3.2 L architettura di MAWeS 43 applicati due filtri: il primo, flt.xsl, produce come output il file out.xml, il secondo, flt2.xml, viene applicato ad out.xml e produce il file out2.xml, alla fine viene avviata una simulazione HeSSE. <? xml version =" 1.0 " encoding ="ISO "?> <! DOCTYPE metafilter SYSTEM " scriptfilter. dtd " > < metafilter filterrepository =" http: // url / dir "> <! -- Filter the nbody file using the flt filter. --> <filter in=" nbody. xml " out =" out. xml " filter =" flt. xsl "> <echo >Filter 1</ echo > </ filter > <! -- Filter the nbody file using the flt filter. --> <filter in=" out. xml " out =" out2. xml " filter =" flt2. xsl " > <echo >Filter 2</ echo > <param name =" param1 " type =" string "> First parameter </ param > <param name =" param2 " type =" int " /> </ filter > < simulation /> </ metafilter > Figura 3.7. Esempio di script per il filtraggio. Figura 3.8. Esempio di applicazione dello script di figura MAWeSclient Il client MAWeS propone un implementazione Java che incapsula e semplifica le azioni necessarie a colloquiare con i servizi di MAWeS. Non implementa la logica legata all ottimizzazione, ma si limita a

45 3.2 L architettura di MAWeS 44 fornire facility per la gestione dei messaggi SOAP e delle directory di documenti MetaPL ed HeSSE che descrivono l applicazione. Di seguito è riportato un frammento di codice che evidenzia le funzioni fornite da MAWeS client: public class MAWeSclient { private MaweswsSoapBindingStub mawesws ; private MAWeSwsServiceLocator servicelocator ; public MAWeSclient ( URL address ) throws ServiceException { servicelocator = new MAWeSwsServiceLocator (); mawesws = ( MaweswsSoapBindingStub ) servicelocator. getmawesws ( address ); } private void addattachment ( File flattachment ) throws IOException {... } private void copyattachmentinfile ( AttachmentPart attpart, File outfl ) throws IOException, SOAPException {... } public long execute ( File dir, File outputdir, String metaplflname, String scriptname, CallTimes ct) throws IOException, RemoteException, SOAPException {... } } public long executeant ( File dir, File outputdir, String scriptname, String target, CallTimes ct) throws SOAPException, IOException {... } Ciclo di esecuzione I client sottomettono la descrizione dell applicazione al core di MAWeS, quindi i servizi del framework eseguono automaticamente le simulazioni necessarie e restituiscono l insieme dei valori dei parametri che individuano la configurazione migliore; i client a questo punto possono riconfigurarsi tenendone conto. Il processo di esecuzione mostrato in figura 3.9 si svolge, al livello logico, nei passi indicati di seguito: 1. Chiamata del servizio da parte del client: questo passo include la gestione del messaggio SOAP e l inclusione, come allegato compres-

46 3.2 L architettura di MAWeS 45 Figura 3.9. Diagramma di sequenza della procedura di ricerca dei parametri. so, di tutti i documenti necessari per la descrizione del software e per le simulazioni; 2. Gestione del messaggio di attivazione del servizio: in questo momento il sistema estrae dal messaggio tutte le informazioni e crea un area temporanea all interno della quale generare le configurazioni ed eseguire le simulazioni; 3. Generazioni dei valori per la singola configurazione: basandosi sulle informazioni inserite nella sezione autonomic del file Meta- PL, viene esplorato il dominio dei parametri, vengono generate, cioè tutte le configurazioni che il progettista ha ritenuto sia utile simulare; 4. Selezione del valore iniziale dei parametri: ai parametri viene assegnato un valore di partenza; 5. Variazione del valore dei parametri: per ogni nuova configurazione si fa variare il valore di un solo parametro per volta; 6. Applicazione dei filtri: ciascun filtro viene applicato in modo parametrico, usando, cioè, i valori dei parametri calcolati nel punto precedente, per specializzare il processo di filtraggio;

47 3.3 Sviluppo di Web Services di tipo autonomic Esecuzione della simulazione: viene attivato il simulatore HeSSE e raccolto l output; 8. Parsing dell output di HeSSE: viene individuato, nell output del simulatore, il valore che esprime il tempo di esecuzione. Se sono necessarie nuove simulazioni per esplorare il dominio dei parametri si torna al punto 5; 9. Raccolta dei risultati: vengono raccolti i risultati delle simulazioni e scelta quella che ottiene il tempo di risposta migliore; 10. Restituzione dei risultati: la configurazione migliore viene impacchettata e rispedita al client come attachment compresso all interno del messaggio SOAP di risposta. L implementazione è stata fatta in linguaggio Java usando Apache Axis come motore Web Services e Apache Tomcat come service provider. Inoltre è stato estensivamente usato il package JUnit per testare le varie funzionalità del framework [55]. 3.3 Sviluppo di Web Services di tipo autonomic Le Applicazioni Web sono fondamentalmente costituite da due elementi: i client ed i servizi; i primi sono i moduli che interagiscono direttamente con gli utenti finali, mentre i secondi contengono un insieme di servizi accessibili tramite interfacce Web Services. Di solito i client possono mantenere lo stato dell applicazione durante l esecuzione e sfruttare i servizi per i compiti di elaborazione, come la manipolazione di dati o l accesso alle basi di dati. Lo sviluppo di nuove applicazioni consiste nella definizione di un nuovo insieme di client con i quali dovranno interagire gli utenti, di nuovi servizi, scritti nell ottica della riusabilità, e della composizione di servizi esistenti. Per ottenere buone prestazioni da un applicazione web, è possibile sfruttare le tecniche di auto-ottimizzazione a tre livelli [42 44]: Livello del server: il sistema autonomo interessa lo strato distribuito sottostante, cioè le azioni di ottimizzazione vengono eseguite al livello del sistema operativo e della rete; Livello del Service Provider: il sistema autonomo influenza il fornitore di servizi, cioè le azioni di ottimizzazione hanno impatto sui

48 3.3 Sviluppo di Web Services di tipo autonomic 47 parametri e sulle politiche di gestione del carico dell insieme dei servizi offerti; Livello dell applicazione: il sistema autonomo influenza le applicazioni utente, modificando l uso delle risorse e le azioni che esse svolgono. Le operazioni di ottimizzazione del livello del server sono di solito affidate agli amministratori di sistema, mentre quelle dei livelli del fornitore di servizi e dell applicazione sono di pertinenza degli sviluppatori delle applicazioni. Questo capitolo si focalizza in particolare sul terzo punto studiando quando e come, i client invocano i servizi di ottimizzazione. Figura Uso di MAWeS al livello delle applicazioni: i client dell applicazione web contengono la logica di controllo delle ottimizzazioni. Uno dei modi possibili è l integrazione nei client che invocano i servizi di ottimizzazione e, quindi, i servizi operativi con i parametri ottimali. Lo schema di principio di questa configurazione è riportato in figura Ciascun client integra un modulo fornito dal framework che fornisce i servizi essenziali insieme a qualche facility. Saranno solo essi a connettersi ai servizi di ottimizzazione per decidere quando e come contattare i server. Naturalmente, questa configurazione è particolarmente adatta quando non si ha il controllo dei servizi applicativi. Una possibilità alternativa può essere quella dell integrazione della logica di ottimizzazione direttamente nei servizi, come mostrato nella figura In questo caso il compito dei client è quello di aggregare i servizi che si adattano automaticamente durante l esecuzione. Questa

49 3.3 Sviluppo di Web Services di tipo autonomic 48 configurazione è più adatta alle situazioni in cui è preferibile una gestione distribuita, o si vuole un ottimizzazione eterogenea, in cui ogni servizio può gestirsi localmente senza la conoscenza complessiva del sistema. Figura Uso di MAWeS al livello dei servizi: ogni servizio sceglie come ottimizzare i propri parametri. Una volta che nell applicazione è stata integrata la logica di autoottimizzazione, è necessario stabilire quando avviare l analisi delle prestazioni e la ricerca dei valori migliori per i parametri. Tra le possibili strategie se ne possono proporre tre più generali: Deploy: le ottimizzazioni vengono valutate solo al momento del deployment del servizio; Service Call: le ottimizzazioni vengono valutate ogni volta che un client chiama un servizio; Reactive: le ottimizzazioni vengono valutate solo in corrispondenza di particolari eventi (ad esempio ad intervalli regolari o picchi di carico). La prima strategia (Deploy), impedisce la riconfigurazione a runtime, e quindi la capacità di adattarsi ai cambiamenti dell ambiente: una volta che il servizio è stato pubblicato è impossibile riconfigurarlo. Questa può essere una strategia accettabile quando l overhead imposto da MAWeS non è ammissibile. Questo overhead potrebbe rendere poco appetibile anche la seconda strategia, quella dell ottimizzazione ad ogni chiamata dei servizi. In seguito a queste considerazioni, nella

50 3.4 Sistemi ad agenti mobili 49 maggior parte dei casi può essere preferibile una strategia basata su eventi. Si noti che in questo contesto le fasi di deployment sono intese come l adattamento del software all ambiente che lo ospita; come sarà chiarito nel seguito, questo adattamento dal punto di vista di questo studio viene fatto in due fasi: la descrizione dell ambiente e la scelta iniziale dell insieme dei parametri. Il modello di architettura risultante è mostrato nella figure Essa è basata sull integrazione dei client MAWeS nei servizi web, ma funziona asincronamente rispetto ad essi. Seguendo una temporizzazione predefinita il client MAWeS avvia l ottimizzazione dei servizi ed aggiorna l insieme dei parametri (azioni a-g in figura 3.12). Quando il client dell applicazione web chiama il servizio, questo si avvia in modo ottimizzato usando i parametri precalcolati (azioni 1-4 in figura 3.12). Usando l approccio basato su reazione, l ottimizzazione può essere avviata facilmente seguendo un profilo di carico; nel momento del deploy al servizio vengono date le informazioni sui tempi in cui il carico dovrebbe cambiare, e le ottimizzazioni vengono lanciate solo negli istanti in cui si prevede sia necessaria una riottimizzazione. 3.4 Sistemi ad agenti mobili La programmazione basata su agenti mobili è un paradigma emergente per la programmazione distribuita; le piattaforme basate su agenti si sono rivelate utili in vari campi come le Grid [2, 66, 75], o le applicazioni basate sui servizi (Service Oriented Architecture, SOA) [25,37]. In questi sistemi sono difficilmente applicabili le tecniche classiche di ottimizzazione, come la taratura ad-hoc o lo sviluppo basato sulla software performance engineering, questo a causa dei continui cambiamenti del contesto di esecuzione, in quanto un agente può sospendersi, trasferirsi su un altro host abilitato alla sua esecuzione e continuare l esecuzione nella nuova destinazione. Quindi la piattaforma che li ospita non ha il controllo completo sullo stato del nodo, così, anche se gli approcci ad agenti mobili possono aiutare lo sviluppo di applicazioni, in pratica l unica soluzione in grado di garantire requisiti critici sembra essere l uso di architetture

51 3.4 Sistemi ad agenti mobili 50 Figura Integrazione di MAWeS in un applicazione basata su Web Services.

52 3.4 Sistemi ad agenti mobili 51 che si auto-configurano. Più in dettaglio, quando un agente si sposta su un nuovo sistema modifica lo stato preesistente, una predizione dell impatto di questo spostamento può aiutare a compiere scelte migliori nella riconfigurazione degli agenti. Per permettere l integrazione tra i sistemi ad agenti mobili e MAWeS, ci si è basati su Aglet Workbench, sviluppato da IBM Japan Research Group [35] con un interfaccia Web Service, in modo da supportare la pubblicazione dei servizi forniti da un agent server. Questo permette di creare, spostare gli agenti e comunicare con essi usando il protocollo SOAP. L agent server viene avviato all interno di un server Tomcat [9], e implementa un bridge SOAP che permette alle applicazione di interagire con gli agenti ospitati localmente o su host remoti. Per usare MAWeS con Aglets, sono state sviluppate nuove librerie di HeSSE per la simulazione dell overhead imposto dagli agenti quando si muovono, si clonano o scambiano messaggi, e una nuova estensione MetaPL per la descrizione del comportamento degli agenti. Come mostrato in figura 3.13, il framework Mawes è stato esteso con due nuove caratteristiche: MAWeS Core System Management Extension: il core è stato arricchito da un nuovo modulo che tiene conto dell ambiente di esecuzione. Il modulo viene eseguito come un daemon: interroga ciclicamente un registry di WS (UDDI) per scoprire nuove piattaforme Aglet e genera nuovi file di configurazione per il simulatore che tengano conto delle nuove piattaforme. MAWeS Client Extension: Il client MAWeS è stato esteso in modo da gestire un insieme di agenti che dovrebbero essere avviati sulle piattaforme target e invia ciclicamente query al core per prendere decisioni riguardo alle possibili riconfigurazioni dell applicazione.

53 3.4 Sistemi ad agenti mobili 52 Figura Lo schema dell estensione del framework Mawes per gli agenti mobili.

54 4 Risultati sperimentali Per validare il sistema sono stati implementati diversi casi di studio. Essendo il framework MAWeS proposto come un servizio con interfaccia Web, è naturale che il primo test-bench sia stato quello delle applicazioni orientate ai servizi. È stata implementata un applicazione di test in grado di autoconfigurarsi al variare delle condizioni di esecuzione senza intervento esterno. Il problema fondamentale legato alla presenza del framework è quello dell overhead introdotto. Nel caso in cui i processi di ottimizzazione siano usati per lanciare nuove istanze di un applicazione con parametri ottimizzati rispetto al carico di sistema atteso questo si ripercuote in un considerevole aumento dei tempi di startup dovuto ai tempi di simulazione ed analisi prima che l istanza ottimizzata sia avviata. Naturalmente l uso del framework può essere vantaggioso se il tempo speso nella simulazione è molto minore rispetto ai tempi di esecuzione dell applicazione. 4.1 Applicazioni orientate ai servizi Il primo degli esempi scelti per valutare il framework, è un applicazione web service che fa l analisi di file di log. Si tratta di un caso di studio semplice ma realistico, che mostra come MAWeS influenza le prestazioni di un applicazione. Per implementarla è stato configurato un Service Provider, un insieme di servizi e un applicazione basata su Web Services. Minimizzare il tempo di risposta di quest ultima è l obiettivo delle ottimizzazioni del framework.

55 4.1 Applicazioni orientate ai servizi 54 Figura 4.1. Schema dell applicazione di test LogAnalysis. I servizi esportati dal server LogAnalysis permettono di analizzare generici file di log (preparati ad hoc per valutare meglio i risultati). Sono fondamentalmente tre (figura 4.2): getloglength: che restituisce le dimensioni del file di log in linee; getlogfragment: che accetta come parametri una dimensione e una posizione all interno del file di log e ne restituisce un frammento preso nella posizione e delle dimensioni indicate; unique: che accetta come parametro un frammento del file di log e restituisce l IP dei client indicati in tale frammento. Come si nota i servizi sono stati scelti con l obiettivo di stressare i sistemi dal punto di vista dell uso della banda, dell I/O e della computazione, più che con la finalità di un analisi efficiente dei log. L applicazione LogAnalysis valuta ciclicamente (ogni T secondi) il numero di accessi di ciascun web client, identificato da un indirizzo IP, analizzando i file di log con i servizi descritti. I client LogAnalysis possono eseguire questa operazione in un singolo passo interagendo, quindi, con il server una sola volta, o in passi successivi usando i servizi getlogfragment e unique. In quest ultimo caso si può verificare una divisione del carico tra più server LogAnalysis, ciascuno dei quali fa

56 4.1 Applicazioni orientate ai servizi 55 Figura 4.2. Class diagram di LogAnalysis riferimento allo stesso file di log. Poiché il client è basato su thread, ogni frammento del file di log è processato concorrentemente. Ogni volta che viene lanciata la scansione dei log, viene variato il numero di thread sul client e l assegnazione di questi thread ai vari server disponibili; in questo modo varia il carico sui nodi di computazione e sulla rete, facendo variare il tempo di risposta. Nei test sono stati valutati solo il carico di CPU e di rete generati direttamente ed indirettamente dall applicazione LogAnalysis. Comunque il simulatore permette di tener conto anche di eventuale carico generato da altre applicazioni che funzionano sui sistemi di test, come mostrato in un successivo caso di studio (cap. 4.2). Uno dei parametri del sistema di ottimizzazione è stato quello della politica di scelta del server a cui ogni client può connettersi. Ogni client può richiedere i servizi a uno qualunque dei server disponibili, nel test sono state previste, però due sole politiche di scelta: una politica statica ed una dinamica. Usando una politica statica, ogni client richiede i servizi sempre allo stesso server, c è un legame statico tra un client ed un server. Usando una politica dinamica un client decide di volta in volta a quale server connettersi usando degli schemi di scheduling predefiniti (ad esempio round-robin). Dalle misure fatte in mancanza di sistema di ottimizzazione è risultato che non c è un netto predominio di una delle due politiche in termini di prestazioni.

57 4.1 Applicazioni orientate ai servizi 56 Figura 4.3. Activity diagram di log analysis

58 4.1 Applicazioni orientate ai servizi 57 public class ClientRequestThread extends Thread { private static final Logger logger = Logger. getlogger ( LogAnalysisTest. class ); public final int clientnum ; public final int requestnum ; private final int numtotservers ; private long elapsed ; private final URL srvurl ; private static LogAnalysisService servicelocator = null ; private final LoganalysisSoapBindingStub las ; public ClientRequestThread ( int numactivesrv, URL url, int num, int reqnum ) throws ServiceException { if ( servicelocator == null ) servicelocator = new LogAnalysisServiceLocator (); clientnum = num ; requestnum = reqnum ; elapsed = 0; numtotservers = numactivesrv ; srvurl = url ; las = ( LoganalysisSoapBindingStub ) servicelocator. getloganalysis ( srvurl ); } public long getelapsedtime () { return elapsed ; } private void work () throws RemoteException { int [] res ; long loglen = las. getloglength (); int fraglen = ( int )( loglen / numtotservers ) -1; } final int from = requestnum * fraglen ; final int to = ( requestnum +1)* fraglen ; // To stress network las. getlogfragment (from, Math. min ( from +1000, to )); // To stress server CPU and I/ O las. uniq2 (from, to ); } public void run () { try { final long time0 = System. currenttimemillis (); work (); elapsed = System. currenttimemillis () - time0 ; } catch ( Exception exc ) { logger. log ( Level. SEVERE, " ERROR "+ exc. getmessage (), exc ); } } Figura 4.4. Frammento di codice dei thread client di LogAnalysis

59 4.1 Applicazioni orientate ai servizi <Task > <Loop iteration ="23"> <Block > <Sleep time =" 240 " /> <WSCall ws=" LogAnalysis " method =" renew " /> < WSlocalworktime time =" 1" / > < Loop iteration =" Nfragments " > <Block > < WSCall ws =" LogAnalysis " method =" getlogfragment " maxfragments ="mf" numfrag ="nf" /> </ Block > </ Loop > <WSCall ws=" LogAnalysis " method =" unique " /> <WSEnd /> </ Block > </ Loop > </ Task > < Mapping > < NumberOfProcesses value =" 5" / > < ProcessID value ="ID"/> < Autonomic > < Parameter name =" NumberOfProcesses " > <Value >5</ Value > <Value >10 </ Value > </ Parameter > < Parameter name =" NumberOfServers " > <Value >2</ Value > <Value >3</ Value > </ Parameter > < Parameter name =" ServerChoicePolicy " > <Value >Static </ Value > <Value > Dynamic </ Value > </ Parameter > </ Autonomic > </ Mapping > Figura 4.5. Frammento della descrizione MetaPL dell applicazione LogAnalysis; nell ultima parte si notano le estensioni autonome

60 4.1 Applicazioni orientate ai servizi 59 La figura 4.5 mostra la descrizione MetaPL dei client LogAnalysis; questa indica esplicitamente i parametri che il sistema dovrà ottimizzare: NumberOfProcesses: il numero di thread sui client LogAnalysis. Questo parametro è legato alla dimensione dei frammenti del file di log: la dimensione di ogni frammento è data dal rapporto tra le dimensioni del file di log e il numero di client; NumberOfServers: il numero di server LogAnalysis; ServerChoicePolicy: la politica di scelta dei server LogAnalysis. L esecuzione dei LogAnalysisClient procede come descritto nel seguito: ogni volta che viene avviata l analisi dei log, il client chiede al framework il numero ottimale dei thread client e dei server Log- Analysis, nonché la politica da usare: statica o dinamica. Il framework esegue una serie di simulazioni preliminari per trovare la combinazione ottimale dei parametri riferita alle condizioni dell ambiente che si verificano (carichi computazionali, traffico di rete,...) Valutazione delle prestazioni del framework Per valutare le prestazioni del framework autonomic, è stato svolto un gran numero di test, con istanze di client LogAnalysis. Ognuno di questi client effettua un analisi dei log a intervalli prefissati (es. T = 240s), in questi test si è assunto che tutto il carico, sia di rete sia computazionale, sia interamente da addebitarsi all applicazione Log- Analysis. Praticamente si è ottenuto ciò inibendo sui cluster di test ogni sorgente di rumore. Inoltre le analisi possono considerarsi sincronizzate, cioè i vari client partono contemporaneamente, se confrontati con i tempi caratteristici dell applicazione. Al fine dei test è stato usato un profilo di carico, indicato dalla linea continua nella figura 4.6. A ciascuno dei passi successivi (impostati a intervalli regolari), il numero dei client LogAnalysis varia secondo quanto riportato dal diagramma, facendo variare di conseguenza il carico del sistema. Per mostrare il funzionamento con feedforward si usa una curva di carico stimata diversa da quella reale, indicata dalla linea tratteggiata. I carichi reali e stimati coincidono su tutta la

61 4.1 Applicazioni orientate ai servizi 60 durata del test tranne in due periodi: da 12 a 13 con una predizione leggermente errata, e tra 19 e 22 con una predizione molto diversa dal carico reale. Il risultato misurato è relativo alla risposta di tutti i client attivi per una singola analisi del file di log. Figura 4.6. Profili di carico reali e stimati: il profilo stimato si discosta da quello iniettato per evidenziare i problemi dovuti agli errori di previsione. Il test è stato effettuato su un cluster basato sulla Rocks Linux Cluster Distribution, composto da un front-end IBM x345, con dual Intel Xeon 2.8 GHz, 1GB Ram, 72 GB RAID disk, e un Blade system con sette nodi computazionali con dual Xeon 2.8 GHz, 1 GB Ram, 72 HD. Il sistema di Web Services è stato sviluppato usando Apache AXIS e Apache Tomcat [9]. Ad ogni nodo è stato assegnato un solo ruolo, server o client, in maniera esclusiva.. Quindi ciascuno è stato, in maniera esclusiva, o uno dei service provider, o un server MAWeS o un client a seconda se offriva i servizi applicativi, quelli del framework di ottimizzazione o conteneva il client applicativo. In questo modo è stato possibile studiare il comportamento del framework in diverse configurazioni. In particolare per la configurazione studiata di seguito sono stati usati: Tre nodi server con piattaforma Web Services Tomcat/Axis su cui sono stati lanciati i servizi applicativi; Un singolo nodo con piattaforma Web Services Tomcat/Axis su cui sono stati lanciati i servizi MAWeS e su cui funzionava il simulatore;

62 4.1 Applicazioni orientate ai servizi 61 Un nodo su cui è stata lanciata l applicazione client. Nella figura 4.7 sono confrontati i tempi di risposta dell applicazione LogAnalysis in assenza di ottimizzazioni autonomic, usando, cioè due configurazioni scelte all inizio dell esecuzione e mantenute per tutte le condizioni di carico. Per le due configurazioni di riferimento, denominate Best Unloaded e Best Mean, sono stati scelti i parametri riportati nella tabella 4.1. La prima corrisponde all insieme di parametri per la configurazione che corrisponde al tempo di risposta minore per un sistema completamente scarico, e si comporta in maniera non ottimale quando il carico è presente. La seconda corrisponde alla configurazione che offre il miglior tempo di risposta medio per qualunque configurazione di carico. Figura 4.7. Autonomic response time vs. two fixed configurations Parametro Best Unloaded Best Mean NumberOfProcesses 4 1 NumberOfServers 4 4 ServerChoicePolicy static dynamic Tabella 4.1. Parametri usati per le due configurazioni di test di figura 4.7 (Best Unloaded e Best Mean). Come descritto in precedenza, uno degli usi più promettenti delle ottimizzazioni basate su strumenti simulativi è la possibilità di usare

63 4.1 Applicazioni orientate ai servizi 62 Metric FF vs NoAd 1 FF vs NoAd 2 Risultato medio -19,55% -35,75% Risultato migliore -61,92% -79,15% Risultato peggiore 9,42% 8,39% Nbest Nworst 8 5 Tabella 4.2. Confronto tra i risultati autonomic e le configurazioni fisse indicate in tabella 4.1. approcci feedforward. Un applicazione può usare i servizi di ottimizzazione per identificare le migliori condizioni di funzionamento quando il sistema non ha ancora raggiunto lo stato a cui ci si riferisce. In altri termini si possono anticipare le necessità. I risultati ottenuti con il metodo basato su feedforward sono stati confrontati con quelli ottenuti usando meccanismi di feedback per le ottimizzazioni. La differenza tra i due approcci sta nei dati usati per calcolare la configurazione migliore dei parametri: nel primo caso si tratta di dati stimati, nel secondo caso di dati misurati. La figura 4.8 mostra il tempo di risposta usando gli approcci a feedforward e con feedback, sotto le stesse condizioni di carico e con le stesse predizioni mostrate usate per la figura 4.6. Il diagramma mostra che approccio basato su feedback propone prestazioni migliori solo in caso di predizioni sbagliate. Figura 4.8. Tempo di risposta di LogAnalysis: confronto tra configurazione basata su feedforward e su feedback.

64 4.2 Applicazioni soft-realtime 4.2 Applicazioni soft-realtime 63 Molte applicazioni, soprattutto in ambito ludico (decoder video, sistemi di gioco online,...), possono tollerare una perdita di qualità nelle proprie elaborazioni, se queste diventano troppo dispendiose in termini di uso di risorse o di tempo di calcolo. Per esempio un avatar che si muove nel mondo virtuale di un videogioco può scegliere un path non ottimale per raggiungere il proprio obiettivo senza che vi siano variazioni apprezzabili nell esperienza dell utente, o un sistema di streaming video può inviare o decodificare dei frame a qualità più bassa garantendo tuttavia i propri servizi. Spesso le variazioni di carico non sono completamente casuali, ma seguono qualche tipo di legge empirica, come ad esempio i server web o di streaming che possono avere picchi di accesso ogni giorno alla stessa ora. Per testare il framework MAWeS con questo tipo di applicazioni è stato scritto un test sintetico che simula il comportamento di un sistema soft real-time. Lo fa eseguendo una serie di unità di lavoro che devono essere portate a termine in uno slot temporale predefinito, ad esempio 2000 ms. Si tratta in realtà di un sistema di conversione di immagini che trasforma dei frame di dimensioni prefissate (720x576 pixels) in formato jpeg usando le librerie di manipolazione delle immagini di Java. È stata progettata usando la metodologia descritta nei capitoli precedenti, basandosi su un architettura a Web Services. Lo schema di principio dell architettura usata nelle due configurazioni di cui sono riportati i dati, è visibile nelle figure 4.9 e Nel prima caso il modulo MAWeSClient è integrato nella parte client dell applicazione, nel secondo caso nella parte server. Il client (figura 4.11) attiva una chiamata al servizio convert, questo raccoglie i dati da convertire li elabora e li registra. Contemporaneamente effettua un analisi del sistema che può cercare configurazioni di funzionamento migliori ed attivare una riconfigurazione. Per dimostrare come i servizi possono adattarsi autonomamente all ambiente, viene applicato un carico esterno ai nodi computazionali (iniettando processi sull host in modo che il servizio non abbia l uso esclusivo delle risorse computazionali) e si studia l evoluzione del soft-

65 4.2 Applicazioni soft-realtime 64 Figura 4.9. Schema dell applicazione WorkHour nella configurazione con i servizi di ottimizzazione integrati nel lato client Figura Schema dell applicazione WorkHour nella configurazione con i servizi di ottimizzazione integrati nel lato server Figura Activity diagram dell applicazione WorkHour

66 4.2 Applicazioni soft-realtime 65 Figura Tempi di risposta con carico eterogeneo: in ogni nodo è stato iniettato un carico diverso ed è sottoposto ad una strategia di riconfigurazione diversa. ware. Nei test che seguono si assume che il carico abbia un andamento a gradino e che sia conosciuto sia il valore sia l istante di applicazione. Il tempo di risposta del servizio è l indice scelto per confrontare soluzioni diverse. Nella figura 4.12 vengono confrontati i tempi di risposta di un servizio che non ha alcun tipo di ottimizzazione con due versioni che hanno due profili diversi di carico esterno atteso. Nella prima configurazione (Pre Optimization) si assume che il carico esterno aumenti prima dell istante di iniezione del carico. Nella seconda configurazione, invece, si assume che il carico esterno sia avviato dopo che questo sia effettivamente iniettato. Si cerca cioè di sbagliare l istante di applicazione dell ottimizzazione prima per difetto, poi per eccesso rispetto ai dati reali. La figura 4.12 dimostra che il caso di Pre optimization riesce ad ottenere la risposta migliore in termini di prestazioni anche se la scelta non è ottimale. Gli strumenti proposti sono basati sull adozione di un approccio feed-forward, basato sull uso del simulatore e dei profili di carico esterno, inoltre sono in grado di usare una strategia a feedback. La figura 4.13 mostra la risposta di un servizio senza adattatività (No Adaptation), con strategia a feedback (Feedback) e a feedforward (FeedFor-

67 4.2 Applicazioni soft-realtime 66 ward). Il diagramma riporta in ascissa l istante di inizio della work unit ed in ordinata la sua durata. Si noti come l approccio feedforward dia i risultati migliori, mentre il feedback, ha alti tempi di risposta per le prime iterazioni (dopo l iniezione del carico), quindi ottimizza le proprie prestazioni. Quando l ottimizzazione è basata su feedback, il sistema riesce ad adattarsi solo dopo un periodo di perdita delle prestazioni. Deve monitorarsi e scoprire la perdita di prestazioni e quando ciò accade può cercare i parametri ottimali attraverso MAWeS. Figura The comparison between system evolution without MAWeS, with feedback and with feedforward MAWeS Quando l ottimizzazione è basata su feedforward, l utente deve stimare alcuni parametri (come ad esempio il numero di accessi ad un sito), quindi studiare l evoluzione del sistema usando la simulazione, ed infine cercare il valore ottimale per i parametri. Non può esservi, quindi un uso ottimale delle risorse quando non è possibile predire effettivamente l evoluzione del sistema (evoluzione tra 8 e 10 secondi in figura 4.13).

68 4.3 Servizi composti Servizi composti Uno degli scenari più comuni nelle architetture orientate ai servizi è quello della composizione, dell aggregazione, cioè, di più servizi, di livello più basso, da parte del servizio direttamente invocato dall utente. In questa prova è stato esteso il programma WorkHour introdotto nella sezione precedente introducendo un nuovo servizio: convertcs. L applicazione effettua una conversione di un numero specificato di immagini (frames) tutte della stessa misura suddividendo il calcolo tra diversi server. Sono stati esplorati due scenari, il primo per analizzare il caso di ottimizzazione su Service Call, il secondo per le ottimizzazioni reattive Servizi composti e riconfigurazione su invocazione Figura Scenario dell applicazione WorkHour nella configurazione con ottimizzazione su invocazione Nel primo caso (figura 4.14) viene affrontata la riconfigurazione su invocazione, l ottimizzazione, cioè, avviene nel momento in cui il client invoca il server, prima dell inizio dei calcoli veri e propri, in modo che questi ultimi possano essere avviati in maniera ottimizzata.

69 4.3 Servizi composti 68 Figura Activity diagram delle caso di servizi composti con ottimizzazione su invocazione Il diagramma delle attività di figura 4.15 mostra le azioni dell applicazione. Inizialmente viene invocato il servizio convertcs, indicandogli il numero di frames da convertire. L implementazione del servizio a sua volta richiede a MAWeS una configurazione ottimale inviandogli i documenti (MetaPL ed HeSSE) che descrivono il sistema nella configurazione attuale. A questo punto il sistema in base al risultato delle simulazioni decide su quali host allocare i calcoli. In particolare in figura 4.14 è mostrato il caso in cui sono state attivate due chiamate, la prima è stata allocata su due dei tre host disponibili. La seconda sul terzo host. Figura Gantt dell evoluzione delle invocazioni dei servizi composti

HTML e Linguaggi. Politecnico di Milano Facoltà del Design Bovisa. Prof. Gianpaolo Cugola Dipartimento di Elettronica e Informazione

HTML e Linguaggi. Politecnico di Milano Facoltà del Design Bovisa. Prof. Gianpaolo Cugola Dipartimento di Elettronica e Informazione HTML e Linguaggi Politecnico di Facoltà del Design Bovisa Prof. Gianpaolo Cugola Dipartimento di Elettronica e Informazione cugola@elet.polimi.it http://home.dei.polimi.it/cugola Indice Il linguaggio del

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

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

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

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Tecniche Multimediali

Tecniche Multimediali Chiedersi se un computer possa pensare non è più interessante del chiedersi se un sottomarino possa nuotare Edsger Dijkstra (The threats to computing science) Tecniche Multimediali Corso di Laurea in «Informatica»

Dettagli

XML: La nascita del linguaggio

XML: La nascita del linguaggio XML: introduzione alla codifica dei testi Con la codifica dei testi si intende la rappresentazione dei testi stessi su un supporto digitale in un formato utilizzabile dall'elaboratore (Machine Readable

Dettagli

Tecniche Multimediali

Tecniche Multimediali Un programma di computer fa quello che gli dici, non quello che vuoi. Legge di Greer (Leggi di Murphy applicate all informatica) Tecniche Multimediali Corso di Laurea in «Informatica» - aa 2010-2011 Prof.

Dettagli

REGIONE TOSCANA GERTIC. Documentazione di progetto. Viale Montegrappa 278/E 59100 Prato (Italy) Telefono +39.0574.514180 Fax +39.0574.

REGIONE TOSCANA GERTIC. Documentazione di progetto. Viale Montegrappa 278/E 59100 Prato (Italy) Telefono +39.0574.514180 Fax +39.0574. REGIONE TOSCANA GERTIC Documentazione di progetto Viale Montegrappa 278/E 59100 Prato (Italy) Telefono +39.0574.514180 Fax +39.0574.551195 www.netstudio.it INFORMAZIONI DOCUMENTO PROGETTO GeRTIC Gestione

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

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE Università degli studi di Ferrara Facoltà di scienze MM.FF.NN. Corso di Laurea Specialistica in Informatica Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

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

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

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame

Dettagli

Settimana I...1. Giorno 1 - Introduzione all XSLT...3

Settimana I...1. Giorno 1 - Introduzione all XSLT...3 Settimana I...1 Giorno 1 - Introduzione all XSLT...3 Generalità su XSLT...3 Introduzione a XML e XSLT... 4 Cos è XSLT?... 5 Che cosa fa XSLT?... 6 Come si presenta XSLT?... 6 XSLT e la famiglia di XML...

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

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

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Sommario Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Introduzione.................................................................................. 1 SOAP........................................................................................

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Survey sui Framework per Testing di Sistemi Basati su Web Services

Survey sui Framework per Testing di Sistemi Basati su Web Services Survey sui Framework per Testing di Sistemi Basati su Web Services Severoni Francesco Facoltà di Scienze Dipartimento di Informatica Università degli Studi - L Aquila 67100 L Aquila, Italia Argomenti Trattati

Dettagli

Applicazioni e Architetture Internet. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma

Applicazioni e Architetture Internet. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma Applicazioni e Architetture Internet 1 Introduzione Introduzione alle architetture a tre livelli Formati di dati per il Web HTML, XML, DTD 2 Componenti dei sistemi dataintensive Tre tipi separati di funzionalità:

Dettagli

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

FormScape V3.1: SUPPORTO XML

FormScape V3.1: SUPPORTO XML FormScape V3.1: SUPPORTO Maggio 2004 FormScape V3, la Soluzione Intelligente per Creare, Gestire, Visualizzare e Distribuire i Tuoi Documenti FormScape V3 Page 1 Introduzione Il formato si sta affermando

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

APPENDICE B Le Active Server Page

APPENDICE B Le Active Server Page APPENDICE B Le Active Server Page B.1 Introduzione ad ASP La programmazione web è nata con la Common Gateway Interface. L interfaccia CGI tuttavia presenta dei limiti: ad esempio anche per semplici elaborazioni

Dettagli

Sommario Capitolo 1 Introduzione Capitolo 2 Tecnologie wireless Capitolo 3 La sicurezza

Sommario Capitolo 1 Introduzione Capitolo 2 Tecnologie wireless Capitolo 3 La sicurezza Sommario Capitolo 1 3 Introduzione 3 Capitolo 2 9 Tecnologie wireless 9 2.1. WAP: standardizzazione e Internet 9 2.2. Statistiche e potenzialità: l e-commerce 11 2.2.1. WAP e il mobile commerce 13 2.3.

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

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

Architetture dei Sistemi Distribuiti

Architetture dei Sistemi Distribuiti Università degli tudi di Roma Tor Vergata Facoltà di Ingegneria Architetture dei istemi Distribuiti Corso di istemi Distribuiti Valeria Cardellini Anno accademico 2008/09 Architettura sw di sistemi distribuito

Dettagli

DATA MANAGEMENT (descrizione)

DATA MANAGEMENT (descrizione) DATA MANAGEMENT (descrizione) (VER 0.1 / 0807) Autori: Andrea Guerrieri Revisioni: Data Autore Note 24/08/2007 Andrea Guerrieri Prima stesura 1 1. INTRODUZIONE Il sistema fornisce all utente e al progettista

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei Centro Nazionale per l Informatica nella Pubblica Amministrazione Gara a procedura aperta n. 1/2007 per l appalto dei Servizi di rilevazione e valutazione sullo stato di attuazione della normativa vigente

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

Architetture Web I Server Web e gli Standard della Comunicazione

Architetture Web I Server Web e gli Standard della Comunicazione Architetture Web I Server Web e gli Standard della Comunicazione Alessandro Martinelli alessandro.martinelli@unipv.it 27 Marzo 2012 Architetture Architetture Web Protocolli di Comunicazione Il Client Side

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

Certificazione di Proxy Applicativi e di applicazioni e servizi di cooperazione di Sistemi Informativi Locali

Certificazione di Proxy Applicativi e di applicazioni e servizi di cooperazione di Sistemi Informativi Locali Certificazione di Proxy Applicativi e di applicazioni e servizi di cooperazione di Sistemi Informativi Locali Ver. 1.0 11 Gennaio 2006 Riferimenti Documentazione CART - Regione Toscana [RT-PDK] Proxy Developer

Dettagli

a cura di Maria Finazzi

a cura di Maria Finazzi Esercitazioni di XML a cura di Maria Finazzi (11-19 gennaio 2007) e-mail: maria.finazzi@unipv.it pagine web: Il trattamento dell'informazione Testo a stampa: Come

Dettagli

Servizi web in LabVIEW

Servizi web in LabVIEW Servizi web in LabVIEW Soluzioni possibili, come si utilizzano. 1 Soluzioni possibili WEB SERVER Dalla versione 5.1 di LabVIEW è possibile implementare un Web server che consente di operare da remoto sul

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

PIANO DI LAVORO (a.s. 2014/2015) Prof.Andrea Luppichini Prof. Marco Fiorentinini DISCIPLINA Informatica

PIANO DI LAVORO (a.s. 2014/2015) Prof.Andrea Luppichini Prof. Marco Fiorentinini DISCIPLINA Informatica Istituto Tecnico Commerciale Statale e per Geometri E. Fermi Pontedera (Pi) Via Firenze, 51 - Tel. 0587/213400 - Fax 0587/52742 http://www.itcgfermi.it E-mail: mail@itcgfermi.it PIANO DI LAVORO (a.s. 2014/2015)

Dettagli

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari Gubiani & Montanari Il DBMS Oracle 1 Il DBMS Oracle Express Edition Donatella Gubiani e Angelo Montanari Il DBMS Oracle Il DBMS Oracle Oracle 10g Express Edition Il DBMS Oracle (nelle sue versioni più

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

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

Al giorno d oggi, i sistemi per la gestione di database

Al giorno d oggi, i sistemi per la gestione di database Introduzione Al giorno d oggi, i sistemi per la gestione di database implementano un linguaggio standard chiamato SQL (Structured Query Language). Fra le altre cose, il linguaggio SQL consente di prelevare,

Dettagli

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori ANALISI 11 marzo 2012 CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Nella newsletter N 4 abbiamo già parlato di Cloud Computing, introducendone

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

SISTEMA DI PREFETCHING CLIENT-SIDE PER TRAFFICO WEB

SISTEMA DI PREFETCHING CLIENT-SIDE PER TRAFFICO WEB UNIVERSITÀ DEGLI STUDI DI ROMA TOR VERGATA Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Progetto per il corso di Ingegneria del Web SISTEMA DI PREFETCHING CLIENT-SIDE PER

Dettagli

Il progetto di ricerca Ellade

Il progetto di ricerca Ellade Il progetto di ricerca Ellade Ellade ELectronic Live ADaptive Learning Gruppo di lavoro Università degli Studi della Calabria, Dipartimento di Matematica Università degli Studi Mediterranea di Reggio Calabria,

Dettagli

ottobre 2008 -Fonti [SSA] Chapter 16, The Functional Viewpoint Luca Cabibbo Punto di vista Funzionale Luca Cabibbo SwA

ottobre 2008 -Fonti [SSA] Chapter 16, The Functional Viewpoint Luca Cabibbo Punto di vista Funzionale Luca Cabibbo SwA Luca Cabibbo Architetture Software Dispensa AS 16 ottobre 2008 1 -Fonti [SSA] Chapter 16, The Functional Viewpoint 2 Obiettivi - Obiettivi e argomenti descrivere il punto di vista Funzionale Argomenti

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

Tecnologie di Sviluppo per il Web

Tecnologie di Sviluppo per il Web Tecnologie di Sviluppo per il Web Applicazioni Web J2EE Framework per il Modello 2 it.unibas.pinco versione 3.2 Questo lavoro è concesso in uso secondo i termini di una licenza Creative Commons (vedi ultima

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012 Architetture dei WIS Prof.ssa E. Gentile a.a. 2011-2012 Definizione di WIS Un WIS può essere definito come un insieme di applicazioni in grado di reperire, cooperare e fornire informazioni utilizzando

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Scriviamo insieme il futuro

Scriviamo insieme il futuro Res User Meeting 2014 con la partecipazione di Scriviamo insieme il futuro Research for Enterprise Systems 1 Generale - 1 Obbiettivo Fornire al Cliente uno strumento a supporto della problematica Legata

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

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

Linguaggi di Programmazione I Lezione 5

Linguaggi di Programmazione I Lezione 5 Linguaggi di Programmazione I Lezione 5 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 1 aprile 2008 Diagrammi UML 3 UML: richiami..........................................................

Dettagli

Monitoraggio della Rete di Assistenza

Monitoraggio della Rete di Assistenza Studio di fattibilità Allegato al Deliverable A Monitoraggio della Rete di Assistenza Fase 1 Anagrafica ASL Comuni assistibili () ESTRATTO Indice del documento A.20 SCOPO DELL APPLICAZIONE...3 A.20.20

Dettagli

PROGETTO AMS Autonomic Maintenance System

PROGETTO AMS Autonomic Maintenance System PROGETTO AMS Autonomic Maintenance System Progettazione e Sviluppo di un PROTOTIPO di Piattaforma Informatica per la Gestione Autonomica, Integrata e Collaborativa della Manutenzione RELAZIONE TECNICO-SCIENTIFICA

Dettagli

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che Prefazione In questo volume completiamo l esplorazione del linguaggio Java che abbiamo iniziato in Java Fondamenti di programmazione. I due testi fanno parte di un percorso didattico unitario, come testimoniano

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

Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi

Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi Soluzioni per la gestione di risorse e servizi A supporto dei vostri obiettivi di business Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi Utilizzate

Dettagli

Linguaggi per il web oltre HTML: XML

Linguaggi per il web oltre HTML: XML Linguaggi per il web oltre HTML: XML Luca Console Con XML si arriva alla separazione completa tra il contenuto e gli aspetti concernenti la presentazione (visualizzazione). XML è in realtà un meta-formalismo

Dettagli

Il sistema IBM DB2. Sistemi Informativi T. Versione elettronica: L01.1.IntroduzioneDB2.pdf

Il sistema IBM DB2. Sistemi Informativi T. Versione elettronica: L01.1.IntroduzioneDB2.pdf Il sistema IBM DB2 Sistemi Informativi T Versione elettronica: L01.1.IntroduzioneDB2.pdf IBM DB2 Il DBMS relazionale IBM DB2 è il prodotto di punta dell IBM per la gestione di basi di dati relazionali

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

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

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica Tecnologie dell informazione e della comunicazione per le aziende CAPITOLO 3: Progettazione e sviluppo

Dettagli

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato SCP: SCHEDULER LAYER a cura di Alberto Boccato PREMESSA: Negli ultimi tre anni la nostra scuola ha portato avanti un progetto al quale ho partecipato chiamato SCP (Scuola di Calcolo Parallelo). Di fatto

Dettagli

XML INVITO ALLO STUDIO EUROPEAN NETWORK OF INNOVATIVE SCHOOLS

XML INVITO ALLO STUDIO EUROPEAN NETWORK OF INNOVATIVE SCHOOLS XML INVITO ALLO STUDIO EUROPEAN NETWORK OF INNOVATIVE SCHOOLS CSS e XML Per formatare i documenti XML è possibile seguire due strade: Quando non c è bisogno della potenza elaborativa di XSL, l utilizzo

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

1. Hard Real Time Linux (Laurea VO o specialistica)

1. Hard Real Time Linux (Laurea VO o specialistica) 20/9/06 Elenco Tesi Disponibili Applied Research & Technology Dept. La Società MBDA La MBDA Italia è un azienda leader nella realizzazione di sistemi di difesa che con i suoi prodotti è in grado di soddisfare

Dettagli

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l.

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l. CRESCO - SPI.2 MAGO Relazione finale sul Progetto MAGO Relativo al contratto tra ENEA e CRIAI avente per oggetto: Analisi e Realizzazione di tool innovativi a supporto delle funzionalità GRID stipulato

Dettagli

FileMaker 12. Guida ODBC e JDBC

FileMaker 12. Guida ODBC e JDBC FileMaker 12 Guida ODBC e JDBC 2004 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker, Inc.

Dettagli

Tecniche di DM: Link analysis e Association discovery

Tecniche di DM: Link analysis e Association discovery Tecniche di DM: Link analysis e Association discovery Vincenzo Antonio Manganaro vincenzomang@virgilio.it, www.statistica.too.it Indice 1 Architettura di un generico algoritmo di DM. 2 2 Regole di associazione:

Dettagli

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Linguaggi e Tecnologie Web A. A. 2011-2012. Language) Stylesheet.

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Linguaggi e Tecnologie Web A. A. 2011-2012. Language) Stylesheet. Corso di Laurea Specialistica in Ingegneria Informatica Corso di Linguaggi e Tecnologie Web A. A. 2011-2012 XSL (extensible( Stylesheet Language) Eufemia TINELLI Contenuti XSL = XSLT + XSL-FO (+ XPath)

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

UX model e Architetture di SI web-based. B. Pernici D. Ardagna

UX model e Architetture di SI web-based. B. Pernici D. Ardagna UX model e Architetture di SI web-based B. Pernici D. Ardagna Conallen, cap. 7,9 Bibliografia Modellazione concettuale: UX model Primo passo di analisi UX: user experience Schermate Modellare la navigazione,

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

Object-Relational Mapping

Object-Relational Mapping Object-Relational Mapping Versione Preliminare Antonella Poggi Dipartimento di informatica e Sistemistica Sapienza Università di Roma Progetto di Applicazioni Software Anno accademico 2008-2009 Questi

Dettagli

19. LA PROGRAMMAZIONE LATO SERVER

19. LA PROGRAMMAZIONE LATO SERVER 19. LA PROGRAMMAZIONE LATO SERVER Introduciamo uno pseudocodice lato server che chiameremo Pserv che utilizzeremo come al solito per introdurre le problematiche da affrontare, indipendentemente dagli specifici

Dettagli

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA

Dettagli

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo F.O.A.M. Free Object Access Method Un introduzione Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo Il protocollo FOAM. FOAM (Free Object Access Method) è un protocollo

Dettagli

Definizione delle interfacce di colloquio fra le componenti

Definizione delle interfacce di colloquio fra le componenti Definizione delle interfacce di colloquio fra le componenti (integrazione documento) 1 DOCUMENTO:. 1.2 Emesso da: EMISSIONE VERIFICA APPROVAZIONE Nome firma Verificato da: Approvato da: Area ISIC LISTA

Dettagli

Siti interattivi e dinamici. in poche pagine

Siti interattivi e dinamici. in poche pagine Siti interattivi e dinamici in poche pagine 1 Siti Web interattivi Pagine Web codificate esclusivamente per mezzo dell HTML non permettono alcun tipo di interazione con l utente, se non quella rappresentata

Dettagli