Facolt di Ingegneria Corso di Studi in Ingegneria

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant tesi di laurea Robustness Testing di middleware DDS-compliant Anno Accademico 2010/2011 relatore Prof. Domenico Cotroneo correlatore Ing. Gabriella Carrozza candidato Sergio Celentano Matr. 885/211

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Contesto e motivazioni Sistemi critici Basati su COTS (Commercial Off-The-Shelf) Complessi Large scale Integrazione di componenti eterogenei Scenari ATC Sistemi navali Sistemi ferroviari LCCIs

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Contesto e motivazioni “The Right Data in the Right Place at the Right Time” Affidabilità Scalabilità Robustezza Realtimeliness Integrazione e complessità minano l’affidabilità complessiva del sistema Necessità di metodologie e tecniche di dependability assessment Focus sulla robustezza

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Obiettivi e contributo COSA § Definizione di una metodologia per la valutazione della robustezza in sistemi middleware COTS based COME § Realizzazione di uno strumento automatico § Generalizzabile § User friendly

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Robustezza Un software si dice robusto se opera correttamente anche in presenza di condizioni anomale [IEEE Std 610. 12. 1990]. Middleware Robustness threats § § configurazione errata uso improprio di API a livello applicativo parametri di ritorno restituiti dal S. O. Hardware induced failures Middleware Robustness testing le API del middleware sono “bombardate” con una combinazione di valori validi e non

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant L’ approccio proposto 1. Analisi delle API del middleware. 2. Definizione del Fault Model e Failure Model. 3. Scelta del workload e dello scenario d’uso più opportuno per la campagna di test. 4. Design e implementazione di un tool per l’iniezione automatizzata dei guasti. 5. Esecuzione delle campagne di test. 6. Analisi dei risultati.

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Il caso di studio: SWIM BOX & Open. Splice DDS Prism. Tech Open. Splice SWIM-BOX § § § Sviluppata per consentire la condivisione dei dati in scenari ATC Interazione tra sistemi “legacy” Basata su diverse tecnologie per la data distribution § JMS § DDS § § § Modello Publisher/Subscriber Fully DDS-compliant Tecnologia Data-centric e Real-Time Discovery automatico dei partecipanti Qualità del servizio customizzabile

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Il tool di FINJ: Java Fault Injection Tool Agisce da wrapper delle API del middleware Intercetta le chiamate effettuate dall’applicazione workload ai metodi pubblici del middleware. Behavioral reflection tramite libreria Javassist. Architettura basata su pattern per la FINJ Sottomissione dei guasti completamente automatizzata Workload rappresentativo Benchmark Touchstone by Prism. Tech. 2 differenti scenari: locale distribuito OLAP DB per l’analisi • dei risultati

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Analisi dinamica Ogni run si compone dei seguenti passi: 1. 2. 3. Selezione del metodo target dalla “method list” Per ogni parametro in ingresso viene individuato un set di faults, dato il tipo del parametro Per ogni fault è previsto un esperimento diverso Dopo ogni esperimento di FINJ è eseguita una golden run per sollevare eventuali hidden failures. Alla fine dell’esperimento il sistema viene ripristinato.

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Scenario Workload: Benchmark Touchstone by Prism. Tech per sollecitare le API del middleware. Scenario: un processo Transmitter che invia 10 messaggi ad un processo Receiver. § Testbed locale § Transmitter e Receiver sono modellati come thread in esecuzione sulla stessa macchina. § Testbed distribuito § Transmitter e Receiver sono collocati su due nodi differenti.

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Campagna dei test, risultati Prism. Tech Open. Splice Community Edition 4. 3 § § 14 metodi analizzati 400 esperimenti effettuati 2 scenari considerati Default Qos: consegna messaggi “Best Effort” Aspetti di rilievo: § § § Fallimenti modellati con scala CRASH Comportamento mediamente robusto (eccezione sollevata conforme alle specifiche) Due fallimenti di tipo “Silent” osservati, uno più grave (messaggi non trasmessi) Fallimenti “hang” non replicabili Nessun evento di tipo catastrophic/abort/hindering osservato.

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant PROS & CONS PROS § § Automatizzazione § una volta configurato, il tool opera in totale autonomia. Generalizzabilità § Minimo effort richiesto per il testing su differenti implementazioni dello standard DDS CONS § § Metodi statici § Al momento il tool di fault injection intercetta i soli metodi pubblici e non-static. Parametri di tipo primitivo § L’iniezione del guasto avviene sui soli parametri di tipo primitivo presenti nella firma del metodo.

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Robustness Testing di middleware DDS-compliant Conclusioni e sviluppi futuri Conclusioni § La metodologia individuata è efficace anche in un contesto complesso come quello dei COTS § I risultati sono valorizzati dalla rappresentatività degli elementi che compongono il caso di studio Sviluppi futuri § § Quality of Service Ampliamento set di parametri in ingresso Ampliamento set di metodi Confronto con altri middleware DDS